<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 9, 2014 at 7:35 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5">On Wednesday 09 July 2014 19:16:32 Aleix Pol wrote:<br>
> On Wed, Jul 9, 2014 at 7:06 PM, Kevin Funk <<a href="mailto:kfunk@kde.org">kfunk@kde.org</a>> wrote:<br>
> > 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>><br>
> ><br>
> > 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<br>
> ><br>
> > annoyed<br>
> ><br>
> > > > me<br>
> > > ><br>
> > > > > >> quite<br>
> > > > > >><br>
> > > > > >> > a bit:<br>
> > > > > >> ><br>
> > > > > >> > There's lots of different naming styles for file, executable<br>
> > > > > >> > and<br>
> > > ><br>
> > > > class<br>
> > > ><br>
> > > > > >> names<br>
> > > > > >><br>
> > > > > >> > for all the unit tests. This makes it hard to identify them<br>
> > > > > >> > when<br>
> > > > > >><br>
> > > > > >> searching<br>
> > > > > >><br>
> > > > > >> > for classes via Quick Open or when looking up test binaries in<br>
> ><br>
> > the<br>
> ><br>
> > > > > >> > build<br>
> > > > > >> > folder.<br>
> > > > > >> ><br>
> > > > > >> > I'm proposing the following naming scheme (something I've<br>
> ><br>
> > 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<br>
> ><br>
> > 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,<br>
> ><br>
> > 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<br>
> ><br>
> > eventually<br>
> ><br>
> > > and look what's in there. For autotest you just "ctest .".<br>
> ><br>
> > 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/<br>
> ><br>
> ><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>
><br>
> No no, I referred to things like duchainify. benchmarks should probably<br>
> stay with autotests or tests, depending on whether they detect regressions<br>
> by themselves.<br>
<br>
</div></div>Okay. But then I don't see the connection with 'ctest .', because right now,<br>
'duchainify' and friends are of course not part of the auto test suite.<br>
<div class=""><br>
><br>
> And yes, it's a possibility, but then we can make sure at least all plugins<br>
> only get 1 set of those. For example the c++ plugin now has:<br>
> $ find . -name tests<br>
> ./cppduchain/tests<br>
> ./parser/rpp/tests<br>
> ./parser/tests<br>
> ./tests<br>
><br>
> Aleix<br>
<br>
</div>Yep. Let's see.<br>
<br>
I've created a bug report (marked as junior job) for the part we kind of<br>
agreed on (I hope):<br>
<a href="https://bugs.kde.org/show_bug.cgi?id=337282" target="_blank">https://bugs.kde.org/show_bug.cgi?id=337282</a><br>
<br>
Maybe we can find a newcomer to work on this in the frameworks branch?<br>
<br>
That'd be awesome :)<br>
<br>
Greets<span class="HOEnZb"><font color="#888888"><br>
Kevin Funk<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Well, let's leave it there. Worst case scenario, we break it into google code-in tasks.</div><div class="gmail_extra"><br></div><div class="gmail_extra">

Aleix</div></div>