Unit testing (once again)

[Aleix Pol]

On Wed, Feb 8, 2012 at 3:18 PM, Miha Čančula <miha at noughmad.eu> wrote:
> 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
>
>
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>

Hi Miha,
I think you're messing yourself a little bit.

>From one side the provider should list all the test and execute them
individually. On the other side, the view will list the tests and let
the user select which ones must be run at a time.

We should decide then UI wise how do we want to run the unit tests.
Maybe we want to only run the tests relevant to the file that is being
edited, or by a subfolder or whatever. This kind of information should
be exposed in the interface that the provider plugins will implement.

To extract the information, the view plugin will load all the plugins
that implement the UnitTestProvider interface and ask for the provided
information. Here's some rough idea of what I think this interface
might have looked like.

class Test {
   QString executable(); //maybe a launcher?
   QMap<QString, QStringList> cases(); //test name with the arguments
to pass to the execution
};

class IUnitTestProvider {
    virtual QMap<KUrl, Test> retrieveTests() = 0;
};

Now what we would need is to figure out is what's the best way to pass
this data.

Unit testing usability depends a lot on how people use them, in the
end it's just regular programs that have some semantics that we want
to adapt to. So we must find a good middle spot where you don't have
to configure how it all works and also you get to configure how you
want to use it, somehow.

Hope that helped!
Aleix