<div dir="ltr">Hi, Friedrich!<br><div><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
        calligra_add_unittest<br>
        calligra_add_integrationtest<br>
        calligra_add_stresstest<br></blockquote><div><br></div><div>I really like you proposal! Now we need to decide on a set of labels for these tests and give them some definition/documentation so people could decide easily, where their test should go. I guess they should be classified by the importance they have on our code and the timeframe they should be fixed in. Here are the definitions I could make up:<br><br></div><div>1) integrationtest --- small and fast unittest that should/can be run before any commit. Should take a couple of seconds to execute and check basic functionality of the class/subsystem. If your commit breaks such test, ideally commit should not be let in, or at least be fixed as soon as possible. Therefore this type of tests should be very stable (run successfully on any type of system with any deps installed) and not use direct PNG image comparison.<br><br></div><div>2) stresstest --- long running test that is executed on the integration server (jenkins). Should take a couple of minutes to execute. The main use case is checking thread safety for structures with concurrent access. Must also be stable (not use PNG comparison) and if a commit breaks a test, must be fixed as soon as possible.<br><br></div><div>3) manualtest --- the tests that should be run and checked before every release. They might not be stable enough (e.g. use comparison of PNG images) and give numerous false failures, so they need human attention when running. If a commit breaks such a unittest, it is recommended to check what exactly has happened, but it cannot block a commit from integration.<br></div><div> <br><br></div><div>We also have benchmarks in Krita, but they are handled by a different make target right now:<br></div><div><br></div><div>4) benchmarks --- conform the same requirements as 'manualtest' category.<br></div><div><br><br></div><div>Probably, we could start some wiki page to document it right from the beginning?<br></div><div><br></div></div>-- <br><div class="gmail_signature">Dmitry Kazakov</div>
</div></div></div>