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
Yes.
> * 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
Andreas
--
You are a fluke of the universe; you have no right to be here.
More information about the KDevelop-devel
mailing list