QtTest conventions

Andreas Pakulat apaku at gmx.de
Wed Apr 23 12:22:48 UTC 2008

On 23.04.08 13:27:00, Manuel Breugelmans wrote:
> Uniform structured code is almost always a positive thing. Unless I overlooked 
> the guidelines for tests are currently not written out. This is what I 
> deduced by looking at the existing QtTests in kdev{elop,platform}:
> * tests should be located in a subdirectory 'tests' directly beneath the 
> module under test


> * files are named after the class under test, in all lower-case with 'test' 
> appended

That one isn't quite true, at least for the qmake tests I grouped the
various testcases by the functionality they test as everything is in 1
class anyway.

> * declaration & implementation go in seperate .cpp and .h

Thats C++ specific, but yes.

> * testcases are named after the class under test in camel-case with 'Test' 
> appended

The rule is actually that usually a filename is using all-lowercase and the
class in the file is named the same just with camel-case.

So in general there's a class that tests certain functionality of
another class and that class is in a file named after the class, but
using lower-case

> * KDEVTEST_MAIN or QTTEST_MAIN macro at the end of .cpp, right before .moc 

IMHO we shouldn't tell people where to put these.

> * test commands are prefixed with 'test'

If you're talking about the functions that contain the actual tests than
I disagree about this one. I'd like to not have test in there as its
completely redundant - at least for QtTest unittests. All slots in that
class are tests automatically and are automatically run by QtTest.

> * fixture methods {init,cleanup}TestCase declared first

I think thats just because you need them before you can execute a test.
I don't think there should be a policy where to put the functions.

> * helper methods and fixture attributes declared private in the testcase

Only if they're specific to that testcase, else they should be in a file
thats used by all tests


You are a fluke of the universe; you have no right to be here.

More information about the KDevelop-devel mailing list