Unit testing (once again)

[Sven Brauch]

Hi,

I think it's a good idea of having a language-independent unit test
manager. Python could use it too, I think.

Greetings

Am 7. Februar 2012 19:40 schrieb Aleix Pol <aleixpol at kde.org>:
> 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
>
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>