Consistent naming scheme for unit tests?

Kevin Funk kfunk at kde.org
Wed Jul 9 17:35:24 UTC 2014


On Wednesday 09 July 2014 19:16:32 Aleix Pol wrote:
> On Wed, Jul 9, 2014 at 7:06 PM, Kevin Funk <kfunk at kde.org> wrote:
> > On Wednesday 09 July 2014 18:51:25 Aleix Pol wrote:
> > > On Wed, Jul 9, 2014 at 6:30 PM, Kevin Funk <kfunk at kde.org> wrote:
> > > > On Wednesday 09 July 2014 18:12:52 Aleix Pol wrote:
> > > > > On Wed, Jul 9, 2014 at 5:54 PM, Aleix Pol <aleixpol at kde.org> wrote:
> > > > > > On Wed, Jul 9, 2014 at 4:10 PM, Milian Wolff <mail at milianw.de>
> > 
> > wrote:
> > > > > >> On Wednesday 09 July 2014 15:50:12 Kevin Funk wrote:
> > > > > >> > Hey,
> > > > > >> > 
> > > > > >> > While working on kdevplatform/kdevelop in the past this one
> > 
> > annoyed
> > 
> > > > me
> > > > 
> > > > > >> quite
> > > > > >> 
> > > > > >> > a bit:
> > > > > >> > 
> > > > > >> > There's lots of different naming styles for file, executable
> > > > > >> > and
> > > > 
> > > > class
> > > > 
> > > > > >> names
> > > > > >> 
> > > > > >> > for all the unit tests. This makes it hard to identify them
> > > > > >> > when
> > > > > >> 
> > > > > >> searching
> > > > > >> 
> > > > > >> > for classes via Quick Open or when looking up test binaries in
> > 
> > the
> > 
> > > > > >> > build
> > > > > >> > folder.
> > > > > >> > 
> > > > > >> > I'm proposing the following naming scheme (something I've
> > 
> > already
> > 
> > > > > >> started
> > > > > >> 
> > > > > >> > doing in kdev-clang):
> > > > > >> > - test_foo.cpp (file name)
> > > > > >> > - test_foo (target name)
> > > > > >> > - TestFoo (class name)
> > > > > >> > 
> > > > > >> > To be applied to all existing unit tests (potentially as a
> > 
> > junior
> > 
> > > > job)
> > > > 
> > > > > >> and
> > > > > >> 
> > > > > >> > for code written in the future.
> > > > > >> > 
> > > > > >> > Advantages:
> > > > > >> > - Easy to look up via Quick Open because of the "Test" prefix
> > > > > >> > - Easy to determine if a given class/file/target is a test,
> > 
> > again
> > 
> > > > > >> because of
> > > > > >> 
> > > > > >> > the prefix
> > > > > >> > - Consistent!!11
> > > > > >> 
> > > > > >> sounds good, +1
> > > > > >> 
> > > > > >> bye
> > > > > > 
> > > > > > Maybe we can follow  how it's usually done in KF5?
> > > > > > - file name: classnametest.cpp
> > > > > > - target name: classnametest
> > > > > > - class name: ClassNameTest
> > > > > > - test name: subproject-classnametest
> > > > > > 
> > > > > > +1 for consistency anyway.
> > > > 
> > > > I find it much more useful to prefix names with "Test", for
> > > > above-mentioned
> > > > reasons. That's also how it's usually done in Qt, for example
> > > > "tst_quickmousearea". Do you have strong objections against this?
> > > > 
> > > > I like the idea about the test name, though. Having them contain the
> > > > module
> > > > name makes sense.
> > > 
> > > I don't love it, but won't oppose it.
> > > 
> > > The quickopen argument is ok, but it's just about swapping the order.
> > > 
> > > > Greets
> > > > 
> > > > > > Aleix
> > > > > 
> > > > > Oh, and separation between autotests and tests is interesting too.
> > > > 
> > > > Good idea as well. Although that's easy to separate by having non-auto
> > > > tests
> > > > not prefixed with "test_", for example "duchainify".
> > > 
> > > Well, the thing is that you'll have to go to the test directory
> > 
> > eventually
> > 
> > > and look what's in there. For autotest you just "ctest .".
> > 
> > You're referring to tests just like benchmarks that shouldn't be part of
> > autotests, right?
> > 
> > So we would end up in a directory structure similar to:
> > tests/
> > - auto/
> > - manual/
> > - benchmarks/
> > 
> > 
> > Yes?
> > 
> > In that case we would end up creating a lot of directories because of the
> > amount of tests/ subfolders throughout our code base, though...
> 
> No no, I referred to things like duchainify. benchmarks should probably
> stay with autotests or tests, depending on whether they detect regressions
> by themselves.

Okay. But then I don't see the connection with 'ctest .', because right now, 
'duchainify' and friends are of course not part of the auto test suite.

> 
> And yes, it's a possibility, but then we can make sure at least all plugins
> only get 1 set of those. For example the c++ plugin now has:
> $ find . -name tests
> ./cppduchain/tests
> ./parser/rpp/tests
> ./parser/tests
> ./tests
> 
> Aleix

Yep. Let's see.

I've created a bug report (marked as junior job) for the part we kind of 
agreed on (I hope):
https://bugs.kde.org/show_bug.cgi?id=337282

Maybe we can find a newcomer to work on this in the frameworks branch?

That'd be awesome :)

Greets

-- 
Kevin Funk


More information about the KDevelop-devel mailing list