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

Peter Dimov wrote:

Hi Atul,

Thanks for sharing your unit tests experience with us! I think each of us will learn lots of new stuff if more people share interesting experiences like this!

I’m quite new to CppUnit and unit testing and I’m trying to figure out what is the best way to organize the tests. Actually CppUnit has the concepts of a test, a suite and a fixture (maybe also others?). Till now I’ve always created a single fixture, which also becomes a test suite, per class.

The thing is that I think I never use the setUp() and tearDown() functions because I never really share data among all tests. So I feel like it would be better to have a suit of test suites per class to better structure the unit tests. My concern is that the tests structure will become more complicated. On the other side I don’t see much sense to use fixtures because most of the time the data used in the test differ at least slightly because otherwise it is impossible to test different things. What I also noticed was that the code of a number of tests is very often the same and only the data is different. In such cases I would prefer to write the code once and then define the input data and check point values as a data test and have all of them run. A similar concept is available in QTestLib. Maybe someone can share their experiences in this respect!

I started reading Test Driven Development by example and the main point as I get it is to start with the test because the tests help you think more of the interface and help you design a better interface. For code that does not have unit tests it definitely makes sense to write the tests because, as you said, unit tests help to do a better refactoring.

Regards,

Peter

atul wrote:Dear all

I just witnessed first hand the power of Unit Testing again… so wanted to share with you all… also as it is all so fresh in my mind ;-)
We were refactoring a large class… the intent was to take the guts out and replace it with STL containers and STL algorithms…

It took us two days to come up with 20 test cases that covered the code well…. And the third day, as we started changing the code, the tests guided us on our way… pointing out where we went wrong ;-)

The next day we used the refacotored class into a non-trivial production code… and presto, it just worked, and performed well and so easy to maintain etc… 900 lines down to 178 lines ;-)

It took a lot of thinking to cover all corner cases with tests but once it was in place, its power is amazing ;-)

Adding a unit test also teaches you how/why some code really works — and they catch the ripple effect — I would say this is the biggest benefit ….
So people roll up your sleeves and write a test or two, and write them often… it would contribute greatly to the overall quality and rest the nagging doubt ( by making this change have I broken something? )

Writing Unit Tests is, I would say, an invlauable skill evey developer should learn about…. It is as vital as using a powerful editor…

Yesterday I went back and polished my Packet test cases and discovered some new tests ;-) And I felt so good after discovering them…

Let me know what you all think…
— Cheerio atul