Unit testing (once again)

[Aleix Pol]

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

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

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