Consistent naming scheme for unit tests?

[Aleix Pol]

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20140709/ea2bc200/attachment.html>