Hi Atul,

Thanks a lot for your comments and suggestions! I’ve been thinking about the library thing, although in another context, and also totally agree with you about including the .cpp files in the tests. Your suggestion to build calitko as a library seems to me like a good idea. I should also be little effort to do so. I’ll update the .pro files accordingly and provide a patch soon.

I was also rethinking the usefulness of the Testing sub-tree. I think it’s a nice example for DRY (Don’t Repeat Yourself) – duplicating the package trees under Testing. I was thinking instead to have a Tests sub-directory in each package directory. This way tests stay with the code they test but are separated from them ;-). For example, BitTorrent packets are implemented in Protocols/BitTorrent/Packets and their tests in Protocols/BitTorrent/Packets/Tests. Similarly we might put stubs for the actual classes in a Stubs sub-directory (e.g. Protocols/BitTorrent/Stubs) and reuse them when testing other packages. Actually Tests and Stubs would be just special kinds of sub-packages meaning also the corresponding namespaces should be used. I think using the namespaces is important to make the generated documentation clearer.

What do you and the others think?

Best regards,

Peter

atul wrote:Hi Peter

Here are my two cents ;-)

1. Make calitko a static lib when compiling for unit tests

2. link tester against this lib

It is imperative that we share sources ( the same .cpp files should be used for creating tester as calitko ). I think we already have it …

However, I am not comfortable with including a source file ( #include “Packet.cpp” ) as is done right now.. Then I need to remember to include Packet.cpp in only one test file and include Packet.h in others… this is odd. We are also increasing coupling ( and going against a long established convention ).

Generating a library solves this problem.

I agree with the SPOT rule / DRY principle you mentioned… I agree with you about now using Fixtures if the data is slightly different… Fixtures are there to help with DRY … in fact when a test gets executed, the following happens:

setUp();

testXYZ();

tearDown();

this makes the tests independent and decoupled from each other… ( and the creation/destruction code is reused )
Right now I am reading

Unit Test Frameworks
by Paul Hamill
Publisher: O’Reilly
Pub Date: November 2004
ISBN: 0-596-00689-6 Pages: 212

and it explains the details nicely .. I have not reached yes the CppUnit chapter but I will jump around and see what it says about this…..

What do you think about this library idea?

— cheers atul