<div dir="ltr">I forgot to add Krita mailing list to the discussion :)<br><div><div><br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Dmitry Kazakov</b> <span dir="ltr"><<a href="mailto:dimula73@gmail.com">dimula73@gmail.com</a>></span><br>Date: Thu, Feb 5, 2015 at 10:12 AM<br>Subject: Re: Getting to 100 % succedding tests (for 2.9), or, simply dropping them all?<br>To: Calligra Suite developers and users mailing list <<a href="mailto:calligra-devel@kde.org">calligra-devel@kde.org</a>><br><br><br><div dir="ltr"><div><div><div>Hi, Friedrich!<br><br></div>My notes about the tests in Krita.<br><br></div>1) Quite a lot of tests in Krita are based on comparing to reference QImage. These tests are really useful for catching regressions and debugging whole subsystems. But they have a few drawbacks:<br><br></div>1.1) Refernce .png files take a lot of space in repository (current solution: <a href="https://answers.launchpad.net/krita-ru/+faq/2670" target="_blank">https://answers.launchpad.net/krita-ru/+faq/2670</a>)<br><br><div>1.2) The rendered images depend on too many things like libraries installed, their version and CPU model (e.g. Vc, FFTW3, CPU capabilities found). It means that the test may run fine on developer's PC, but fail on jenkins.<br><br><br></div><div>2) Consequence of 1): from time to time we should manually check what exactly is wrong with the test. Is it a pixel drift or a real problem.<br><br></div><div>3) I am firmly against disabling failing unittests from the build system. We had quite a few cases when the tests were simply forgotten and rotten after being disabled from build, since we have no system for controlling it. Spamming (already overloaded) bugzilla is not a solution as well.<br><br></div><div>4) Is it possible to add some tagging to unittests? Like in cmake:<br><br>kde4_add_unit_test(KisDummiesFacadeTest <br>TESTNAME krita-ui-KisDummiesFacadeTest  <br>TESTSSET integration # <----------------------------special tag<br>${kis_dummies_facade_test_SRCS})<br></div><div><br>kde4_add_unit_test(KisZoomAndPanTest <br>TESTNAME krita-ui-KisZoomAndPanTest  <br>TESTSSET extended # <----------------------------special tag<br>${kis_zoom_and_pan_test_SRCS})<br><br></div><div>So that we could have several sets of tests:<br><br></div><div>make test<br></div><div>make test integration<br></div><div>make test extended<br><br></div><div>There is one important point: *all* the test sets should be compiled when KDE_BUILD_TESTS==on<br><br></div><div>5) It would also be nice to be able to choose different subtests of one executable to be in different subsets. Though I am not sure whether it is doable.<br><br><br></div><div>As a conclusion:<br><br></div><div>If we had the tests tagging system implemented before the release, we could just tag the failing one with 'fix-later' or something.<br></div><div><br><br></div><div><br></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Feb 5, 2015 at 9:11 AM, Friedrich W. H. Kossebau <span dir="ltr"><<a href="mailto:kossebau@kde.org" target="_blank">kossebau@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
currently Calligra (2.9 & master) has 313 tests. Those tests could be used to<br>
automatically catch regressions (even better that CI runs them on every push,<br>
so we do not have to to run them ourselves every time) and thus save time<br>
compared to only users starting to see problems after a release, reporting<br>
them incorrectly in the issue tracker and then devs taking time to finding the<br>
real problem and cause.<br>
They also could be useful during the port to Qt5/KF5, as they reassure to a<br>
good degree things have been moved the right direction.<br>
<br>
Just, other than a commit breaking the build, a change resulting in a test<br>
suddenly failing does not immediately pos a problem for everyone, so it seems<br>
easy to just ignore that (and fix it tomorrow, well, the other tomorrow, ah,<br>
next WE perhaps).<br>
<br>
-> problem 1: no mechanism to enforce people to fix tests they broke<br>
<br>
<br>
CURRENT SITUATION<br>
<br>
Just... now I have be the bad boy here and point to<br>
<a href="http://build.kde.org/job/calligra_stable/test/?width=800&height=600" target="_blank">http://build.kde.org/job/calligra_stable/test/?width=800&height=600</a><br>
There are around ~40 tests failing, i.e. 13 %.<br>
<br>
Which means 10 more failing tests then at the begin of 2.9 branching, where it<br>
was ~30:<br>
<a href="http://build.kde.org/job/calligra_master/Variation=All,label=LINBUILDER/1293/" target="_blank">http://build.kde.org/job/calligra_master/Variation=All,label=LINBUILDER/1293/</a><br>
<br>
(And the last build for master right now still visible on build.kde,org from<br>
26.11.2014 had only 26 of 314 failing:<br>
<a href="http://build.kde.org/job/calligra_master/Variation=All,label=LINBUILDER/1235/" target="_blank">http://build.kde.org/job/calligra_master/Variation=All,label=LINBUILDER/1235/</a>)<br>
<br>
Now tests are not coming without a price, everyone waiting on the result of a<br>
Calligra CI build (or locally) knows how much time they take, and if it is<br>
only linking.<br>
<br>
-> problem 2: running current tests takes a lot of time, too much time locally<br>
<br>
<br>
PROPOSAL A<br>
<br>
Given 10 more failing tests (but no added tests) since the branching of 2.9,<br>
where actually things should have gotten more stable and correct, we should<br>
ask ourselves, who is actually looking at those tests. Anyone?<br>
<br>
So could we just get rid of them if noone is? :) Would save a very, very big<br>
amount of cpu cycles and hard disk space for everyone, including CI. And also<br>
code that would need porting.<br>
<br>
<br>
PROPOSAL B<br>
<br>
You are about to hit your Reply button hard after reading proposal A, because<br>
you actually prefer tests? Actually I do as well, and those people who spend<br>
the effort to write, review and maintain all those tests surely also did.<br>
<br>
So how could we get back to using the tests as first class utility in our<br>
Calligra development? With e.g. CI reporting STABLE(=no failing tests) builds<br>
every time?<br>
<br>
For fixing problem 2 we should separate the current tests into unit tests (so<br>
those simply testing one thing while mocking the rest of the system as much as<br>
possible), integration tests and other types of tests.<br>
And make sure that unit tests take less then seconds to run, so no one is<br>
stopped from using them as part of their workflow, e.g. before pushing their<br>
latest changes to the central repo. "make all test" should be a normal habit.<br>
And leave running all the longer running tests for the CI, he, that's what it<br>
is for.<br>
-> task T0: specify/document different test types (Calligra wiki/build system)<br>
-> task T1: go through all the tests and mark those tests which can be<br>
considered quickly runnable unit tests, integration tests, other tests<br>
<br>
Even with that test categorization, there is a number of tests failing<br>
currently that need fixing. Ideally before the 2.9 release and the port. Some<br>
of them are failing since ages (e.g. diff between<br>
<a href="http://build.kde.org/job/calligra_master/Variation=All,label=LINBUILDER/1235/testReport/" target="_blank">http://build.kde.org/job/calligra_master/Variation=All,label=LINBUILDER/1235/testReport/</a><br>
<a href="http://build.kde.org/job/calligra_stable/1829/testReport/" target="_blank">http://build.kde.org/job/calligra_stable/1829/testReport/</a><br>
)<br>
-> task T2: find all the long-time failing tests, disable from build, possibly<br>
tag as JJ bugs to fix them)<br>
-> task T3: list all the new failing tests and lets fix them by everyone ASAP<br>
<br>
For fixing problem 1, this is a social problem. People need to be aware of the<br>
tests (guess some might not) and value those tests.<br>
No idea if future CI systems deployed could enforce rejection of commits that<br>
break tests, but ideally people simply feel responsible for breaking tests,<br>
like they feel responsible for breaking the normal build.<br>
<br>
Personally I see tasks T2 and T3 as something to be done first, best before<br>
2.9 release. See me subscribed to making that happen :)<br>
<br>
But first, please your thoughts and feedback on this.<br>
<br>
Cheers<br>
Friedrich<br>
_______________________________________________<br>
calligra-devel mailing list<br>
<a href="mailto:calligra-devel@kde.org" target="_blank">calligra-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/calligra-devel" target="_blank">https://mail.kde.org/mailman/listinfo/calligra-devel</a><br>
</blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br><div>Dmitry Kazakov</div>
</font></span></div>
</div><br><br clear="all"><br>-- <br><div class="gmail_signature">Dmitry Kazakov</div>
</div></div></div>