Unit testing (once again)

henry miller hank at millerfarm.com
Tue Feb 7 20:12:13 UTC 2012

Makes sense. Just make sure that my cmake project that doesn't use ctest (don't ask) can implement a custom solution for our setup if I ever get around to writing it.

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Aleix Pol <aleixpol at kde.org> wrote:

On Tuesday 07 February 2012 18:00:36 Miha Čančula wrote:


I had a grand idea of finishing and integrating the unit testing plugin in KDevelop over the last summer. Unfortunately, I ended up working on something else all summer, so the testing idea got forgotten. However, now I have some free time on my hands again, and I started refactoring and partially rewriting the whole plugin. 

Compared to the existing implementation, it now has a cleaner interface-implementation separation, a tree view similar to the one in the project view, and is smaller. I made a scratch repo for it at http://quickgit.kde.org/index.php?p=scratch%2Fmihac%2Fkdev-unit-test.git&a=summary. So far I mostly moved code around and only written a little of my own, but now I am at the point where new code would have to be written, and I turn to you for suggestions. Basically, I see three options. 

1. Keep the whole thing in a plugin. This means a separate view for the test tree and their output, and it would only work with CTest. It is basically what's there now. For KDE/C++ it is enough, but other languages have their own test frameworks. 

2. Separate the general view code in one plugin, and the CTest code in another, with a single new interface in Kdevplatform. The view plugin basically loads the test runner plugin for each project. Not much changes, except the possibility of using other test frameworks. The interface doesn't have to be used from anywhere within KDevelop, only for plugin loading and dependency, but uses could be added later. 

3. Integrate it all the way into the Project framework, adding a new ITestController interface in projects. A possibility is also a custom ProjectBaseItem subclass for showing the tests inside the project view. 

Personally, I am leaning towards 2, but it requires (minor) changes to Kdevplatform, so I better ask first. Otherwise, I'll go with 1 as it covers most KDE projects. The third option is there only if you feel the need to have unit testing integrated with other services, like automatic running of all tests before committing, and showing tests on the project tree. It also means more work, so I wouldn't do it without at least some help from the core team. 

If I get an "OK" for going the second route, I'll post a review request where it would be easier to discuss the new interfaces. 

I am not a regular KDevelop developer, but I use it every day, so I thought this might be a good way of becoming one.

Thank you, 

Hi Miha!

First of all, I'm happy you're committed to taking over the Unit Test framework, it's something we really need! :)


In my opinion it shouldn't be linked to the project manager, but a different interface that the project manager might implement. (think of python or ruby projects). What I'd do is something like we do in VCS, where you identify a provider for the project who reports the relevant cases.


A provider can be ctest for cmake (it can be implemented by the project itself) but you can have different ones for qmake or python projects. A test entry would be some executable+arguments pair to be run.


Do you guys think it makes sense? :P


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120207/f8b25796/attachment.html>

More information about the KDevelop-devel mailing list