QtTest conventions

Andreas Pakulat apaku at gmx.de
Wed Apr 23 17:03:11 UTC 2008

On 23.04.08 17:20:55, Manuel Breugelmans wrote:
> On Wednesday 23 April 2008 14:22:48 Andreas Pakulat wrote:
> > > * 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.
> I'm fine with either, the majority of the existing kdev test commands 
> have 'test' prefixed though. On the other hand, newer frameworks (JUnit4) 
> abandon it indeed. CppUnit, PyUnit and JUnit3 still require or recommend it.
> The biggest pro for keeping such a naming convention for QtTests is 
> readability. Especially in larger testcases the distinction between a command 
> and a helper might fade. The slots 'annotation' is only available in the 
> header, so not directly obvious. This is indeed only a tiny plus, possibly 
> outweighted by the redundancy.

Well, I tend to write separate classes for helper stuff or macro's so
thats not a problem for me personally. I do see your point, but still
this is something the test-writer should decide, we may of course have a
hint that if one uses helper functions in the same class prefixing the
tests with test might be a good idea.

> > > * 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.
> I meant in the class declaration.

Yes, me too. The order of things really isn't that important actually,
especially if you use an IDE that has good code navigation. You simply
stop caring wether the functions are ordered in the .h and .cpp in the
same way or where a certain function is put to. And as KDevelop devs we
should encourage people to use our IDE of course :)


You're almost as happy as you think you are.

More information about the KDevelop-devel mailing list