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