Unit testing (once again)

[Miha Čančula]

Hello!

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,
Miha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120207/ed659fcd/attachment.html>