Re: A simpler test configuration…

Hello Everybody,

The current structure is not too different from what Atul was suggesting. The plan now is to have a single test file per class but in a separate directory:

Gnutella/Packets/Bye.cpp -> Testing/Gnutella/Packets/ByeTest.cpp

There are already two separate qmake project files and consequently two separate Makefiles. With slight modifications to calitko.pro it should be possible to automatically run the unit tests.

Why different directories?

The first reason is that source code directory will be just the implementation of a class. Unit tests and all related files, like test data in test files, will be in a separate directory. I think that will be clearer than the “put it all in one place” alternative.

The second reason is related to object files. Now calitko.pro specifies the configuration object_with_source. This means that the object file is placed in the same directory as the source file. The reason we use this option is that we have some files with the same name (but in different directories of course). qmake does not generate correct Makefiles when OBJDIR is set to debug, for example. In that case only one object file gets compiled and the others with the same name not.

Some time ago I modified qmake to create correct Makefiles by adding a number after the name of object files with duplicate names. I even submitted my patch to Trolltech but it was indisputably rejected! The reason they gave me was that not all build systems would support that (which could be true although I don’t believe it). I was even told that it’s a terrible idea to have duplicated filenames in a project. I must subdivide the project in smaller projects to go around this issue… Yes, sure, and compile the precompiled header 20 times for each of the sub-directories? I tried to convince them somehow but they didn’t seem to care. Pity!

object_with_source solves only part of the problem. All moc files are generated in the project root. I fixed that as well. I first had to modify moc.prf and when I did so I encountered a number of bugs in qmake, for which of course I created a patch and submitted it to Trolltech. Whey acknowledged the bugs were there and although I provided them bugfixes as well, they scheduled the fix release to be Qt 4.3, which is probably like 1 year away! Cool, isn’t is? Ok, I see their point that they do not want to change too much shortly before the release of 4.2, but… if I were Microsoft, I’m quite sure they would have fixed the issues for 4.2. Pity again!

Now, back to the problem! We cannot have two make files that build the same source files because due to object_with_source they will overwrite each other’s object files. If the generated object files would be identical, then that’s not a problem. Object files will not even be overwritten. The problem comes when, for testing purposes, we compile A.cpp and we’ll need to use a stub of class B class instead of the real one. The resulting A.o files would be different. Now that’s the reason that BinaryReaderTest.cpp includes BinaryReader.cpp – to compile the symbols for BinaryReader together with the symbols for BinaryReaderTest and avoid conflicts.

To be honest, I still haven’t thought about all the implications of this structure and I wouldn’t be able to do so until we already have some real examples. If someone of you is more experienced with unit testing and test automation in general, please give some feedback!

I am open to any suggestions or ideas! I’ll be waiting for a few more days before committing, so you will have tome to experiment. Even after I commit changes to the system will be done of course.

Sorry for the length of this post!

Regards,

Peter

atul wrote:Dear Peter,

A simpler configuration would be to maintain a test file for each class file..

So Bye.cpp -> TestBye.cpp

LocalPeer.cpp -> TestLocalPeer.cpp

We could also maintain two separate makefiles and trigger the build and run of the unit tests from the calitko make file

Would you like to post a relpy?


This post is a reply to:
A simpler test configuration…
Dear Peter, A simpler configuration would be to maintain a test file for each class file.. So Bye.cpp -> TestBye.cpp LocalPeer.cpp -> TestLocalPeer.cpp We could also maintain two separate makefiles and trigger the build (more...)

No follow-ups yet.