<p>Hello!<br></p><p>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. </p>


<p>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 <a href="http://quickgit.kde.org/index.php?p=scratch%2Fmihac%2Fkdev-unit-test.git&a=summary">http://quickgit.kde.org/index.php?p=scratch%2Fmihac%2Fkdev-unit-test.git&a=summary</a>. 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.</p>


<p>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. <br>
</p><p>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. <br>
</p><p>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.</p>

<p>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. <br>
</p><p>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. <br></p><p></p><p>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.</p>
Thank you, <br>Miha<br>