Unit testing (once again)

[Miha Čančula]

Thanks Millian, yes I am a student and I even applied for this thing at
GSOC last year, but as I said I ended up working for Orange instead (which
I'm still a bit sorry for). So I'm trying to make up now :)

2012/2/8 Milian Wolff <mail at milianw.de>

> I think this should be done using our plugin architecture, you can
> "provide"
> interfaces in a plugin and other plugins can then "require" interfaces.
> That
> makes it possible to do what you want I think. Take a look at e.g.
> IMakeBuilder and such in kdevelop/projectbuilders/makebuilder/*
>
> cheers
>
(and what Aleix said):

I'm not sure I understand completely, so let me explain my thinking better.
The way I envisioned the structure is:

 A) One plugin (let's call it TestViewPlugin) to show all available test.
 B) An interface (ITestProvider, maybe a different name) that specialized
plugins (what I called "generator" inappropriately, "provider" is probably
closer), which find tests, and run them. Since the tests can be nicely
arranged in a tree, I think a tree structure for tests is appropriate. For
CTest with Qt, this is a three-level structure (Project -> executable ->
function). So the Provider(B) would generate the Test tree and send it to
View(A) for display.

Now plugins aren't supposed to link to eachother, so B-plugins shouldn't
link to A or vice versa. However, they should be able to share data (B must
tell A of all the tests it found, and A should tell B which ones to run).
So I would add a shared data class (call it UnitTest or TestCase) for
holding [name, executable, arguments, parent, children]. Alternatives that
I can think of is having the B-plugins provide a QAbstractItemModel (which
also make it hard to display tests for different projects in the same
treeview),  having the TestCase class completely abstract, or simply
storing everything in the A-plugin. However, all of these complicate the
B-plugins with code that could be shared. There are probably other options,
so I'd be happy for suggestions.

Millian, if I understand you correctly, you want to define interfaces in a
plugin, like IMakeBuilder (and now that I did look around, IExecutePlugin
and IExecuteScript) does. But that requires cross-including between
makebuilder and its user cmakebuilder. However, in my case, I would like to
share a concrete class, along with its implementation.



> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120208/ccd10fe5/attachment.html>