<div class="gmail_quote">2012/4/9 Milian Wolff <span dir="ltr"><<a href="mailto:mail@milianw.de">mail@milianw.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey all,<br>
<br>
today I finally took some time to review / test the unittest branches a bit.<br>
It's coming along nicely but there are still a few things to do:<br>
<br></blockquote><div>Hey, thanks! I'm sorry I didn't see your mail before. <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
# Test Population<br>
<br>
Right now, the user must manually click the "reload" button in the test view<br>
to trigger a test-find-job for the loaded projects. That is very unintuitive<br>
and must be improved. For CTest I think that the tests should be added right<br>
from the cmakemanager, making the ctestprovider superflous (instead, make the<br>
cmakemanager a testprovider). </blockquote><div>I realize that, and I have already changed some behavior to work in this way. I left the Reload button there for cases where the automatic fetching is not reliable and for removing tests. <br>
 </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The question there is: How to "remove"<br>
obsoleted/removed unit tests?<br>
<br>
I.e. if a user removes a kde4_add_unit_test or similar in a CMakeLists.txt -<br>
how can we know that and remove the related testsuite from the testcontroller?<br></blockquote><div>Not only that, tests can also be changed (stuff renamed, cases added or removed). So far there is no functionality to check and report this. Being rather time-limited (again), I kept the short-term solution of the Reload button. I think removing test suites or cases is a rare-enough action. <br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
For the PHPUnit provider I'd similarily make the phpplugin itself the plugin<br>
provider (obsoleting the additional plugin). Then, we can just report new<br>
tests whenever we find a class inheriting from the appropriate PHPUnit class.<br>
The big question here is again removal of oudated tests... And additionally,<br>
the found tests should be cached I think, so that we do not have to reparse<br>
the whole project just to find the unit tests. Ideas?<br>
<br>
# QTest != CTest<br>
<br>
I see that the current ctest provider runs "$testbinary -functions" to find<br>
the test functions of a test suite, but that is a QTest feature... With ctest,<br>
you can add anything as a test and I'm not sure whether the above is "OK"...<br>
Ideas?<br></blockquote><div>Well, it tries to run the test as if it's made with QTest. If it is not, no cases are reported (as CTest doesn't support naming individual test cases), but the suite can still be run. I checked this with some tests from the Veritas plugin. <br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
# API<br>
<br>
The TestResult API needs to be extended, I think with at least a<br>
TestCaseResult member. After all, there could be unit tests without<br>
distinguishable child "functions" (see above). Furthermore, if a test fails<br>
completely (e.g. the PHP one when you don't have PHPUnit installed), then we<br>
need a way to mark the whole suite as failed. Probably more needs to be done.<br></blockquote><div>Agreed, thet's why I indroduced a new struct. <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
I furthermore severly dislike ITestController::notifyTestRunFinished() - this<br>
should be removed together with the testRunFinished. Instead, create a TestJob<br>
class that<br>
<br>
a) holds the testresult (this should *not* be put into the testsuite!)<br>
b) has the proper signals when a test failed/finished etc. pp.<br></blockquote><div>Hm. I have thought about this, it probably is the better API, so that more than one result per suite can be stored if needed. However, it would need to be a subclass of OutputJob, so I'm not sure where exactly to put it. The util library?<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
# UI & WorkFlow<br>
<br>
The current UI needs some love, first of all - proper icons. Ideas? I don't<br>
like the current choice but have no idea what else we could use...<br></blockquote><div>Neither do I, I specifically included different icons for different levels to see which ones look better. I still don't know, input here would be valuable.  <br>
<br>Additionally, I don't really like the actions in the toolbar and context menu. Any idea how could running, jumping to source be accomplished better?<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
Furthermore, it's pretty bad that when you run multiple test suites, only the<br>
results of the last one stay visible. Instead, the jobs output should somehow<br>
be concatenated. And one must be able to jump to failures somehow, similar to<br>
the navigation between compiler errors.<br></blockquote><div>That's similar to what running "ctest" does. It is something I have in plan, but I'm not sure how it should look yet. <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
The tree view also does not indicate which suite is currently being run, at<br>
least some icon should be changed or so.<br></blockquote><div>That's because I don't know which icon this should be. Those "task-*" icons seem to be out of place there.  <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
Very important for me would also be a way to quickly run unit tests. I think<br>
we need some dialog, similar to what you see when you press "j" in Kmail to<br>
jump to a different folder. There, the last executed test suite should be pre-<br>
selected. Typing filters the result set and enter would execute all visible<br>
tests.<br>
<br>
# Conclusion<br>
<br>
I hope you all start testing the unittest branch and helping out. Many thanks<br>
to Miha for starting this, good job! Lets hope we can ship 4.4 with this<br>
feature!<br></blockquote><div>Thank you for the feedback. <br><br>Unforturtunately, I must say that my schoolwork has caught up with me again (you may notice the drop in my activity), and I think my progress will be a little  slow for the next couple of weeks as well. In any case, I'll do my best. <br>
<br>If it's OK, I'll introduce a common TestJob, change the API for test results, and/or complete the automatic finding of tests next. <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
Bye<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Milian Wolff<br>
<a href="mailto:mail@milianw.de">mail@milianw.de</a><br>
<a href="http://milianw.de" target="_blank">http://milianw.de</a></font></span><br>--<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
<br></blockquote></div><br>