<div class="gmail_quote">2012/2/8 Aleix Pol <span dir="ltr"><<a href="mailto:aleixpol@kde.org">aleixpol@kde.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Wed, Feb 8, 2012 at 3:18 PM, Miha Čančula <<a href="mailto:miha@noughmad.eu">miha@noughmad.eu</a>> wrote:<br>
> Thanks Millian, yes I am a student and I even applied for this thing at GSOC<br>
> last year, but as I said I ended up working for Orange instead (which I'm<br>
> still a bit sorry for). So I'm trying to make up now :)<br>
><br>
><br>
> 2012/2/8 Milian Wolff <<a href="mailto:mail@milianw.de">mail@milianw.de</a>><br>
>><br>
>> I think this should be done using our plugin architecture, you can<br>
>> "provide"<br>
>> interfaces in a plugin and other plugins can then "require" interfaces.<br>
>> That<br>
>> makes it possible to do what you want I think. Take a look at e.g.<br>
>> IMakeBuilder and such in kdevelop/projectbuilders/makebuilder/*<br>
>><br>
>> cheers<br>
><br>
> (and what Aleix said):<br>
><br>
> I'm not sure I understand completely, so let me explain my thinking better.<br>
> The way I envisioned the structure is:<br>
><br>
>  A) One plugin (let's call it TestViewPlugin) to show all available test.<br>
>  B) An interface (ITestProvider, maybe a different name) that specialized<br>
> plugins (what I called "generator" inappropriately, "provider" is probably<br>
> closer), which find tests, and run them. Since the tests can be nicely<br>
> arranged in a tree, I think a tree structure for tests is appropriate. For<br>
> CTest with Qt, this is a three-level structure (Project -> executable -><br>
> function). So the Provider(B) would generate the Test tree and send it to<br>
> View(A) for display.<br>
><br>
> Now plugins aren't supposed to link to eachother, so B-plugins shouldn't<br>
> link to A or vice versa. However, they should be able to share data (B must<br>
> tell A of all the tests it found, and A should tell B which ones to run). So<br>
> I would add a shared data class (call it UnitTest or TestCase) for holding<br>
> [name, executable, arguments, parent, children]. Alternatives that I can<br>
> think of is having the B-plugins provide a QAbstractItemModel (which also<br>
> make it hard to display tests for different projects in the same treeview),<br>
> having the TestCase class completely abstract, or simply storing everything<br>
> in the A-plugin. However, all of these complicate the B-plugins with code<br>
> that could be shared. There are probably other options, so I'd be happy for<br>
> suggestions.<br>
><br>
> Millian, if I understand you correctly, you want to define interfaces in a<br>
> plugin, like IMakeBuilder (and now that I did look around, IExecutePlugin<br>
> and IExecuteScript) does. But that requires cross-including between<br>
> makebuilder and its user cmakebuilder. However, in my case, I would like to<br>
> share a concrete class, along with its implementation.<br>
><br>
><br>
>><br>
>> --<br>
>> Milian Wolff<br>
>> <a href="mailto:mail@milianw.de">mail@milianw.de</a><br>
>> <a href="http://milianw.de" target="_blank">http://milianw.de</a><br>
><br>
><br>
><br>
</div></div><div class="im">> --<br>
> KDevelop-devel mailing list<br>
> <a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
> <a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
><br>
<br>
</div>Hi Miha,<br>
I think you're messing yourself a little bit.<br></blockquote><div>:) <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>From one side the provider should list all the test and execute them<br>
individually. On the other side, the view will list the tests and let<br>
the user select which ones must be run at a time.<br>
<br>
We should decide then UI wise how do we want to run the unit tests.<br>
Maybe we want to only run the tests relevant to the file that is being<br>
edited, or by a subfolder or whatever. This kind of information should<br>
be exposed in the interface that the provider plugins will implement.<br></blockquote><div>Yes, I did not think of that. So instead of having a tree structure, you propose <br>indexing by URL, and relying on the view to display it in some way. <br>
I suppose because I started with the Veritas library which creates such a tree, I didn't <br>even consider any different indexing. But it does make more sense to me. <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
To extract the information, the view plugin will load all the plugins<br>
that implement the UnitTestProvider interface and ask for the provided<br>
information. Here's some rough idea of what I think this interface<br>
might have looked like.<br>
<br>
class Test {<br>
   QString executable(); //maybe a launcher?<br>
   QMap<QString, QStringList> cases(); //test name with the arguments<br>
to pass to the execution<br>
};<br>
<br>
class IUnitTestProvider {<br>
    virtual QMap<KUrl, Test> retrieveTests() = 0;<br>
};<br></blockquote><div>This is basically what I had in mind, except for the tree structure (and asynchronous operation, and checking whether this particular provider is the right one for a project). My question is where to put the Test class. It's possible to avoid it altogether by replacing it with a QPair<QString, QStringList> or something even more convoluted, but that looks ugly. On the other hand, an ugly typedef is still better than a whole separate library.  <br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Now what we would need is to figure out is what's the best way to pass<br>
this data.<br>
<br>
Unit testing usability depends a lot on how people use them, in the<br>
end it's just regular programs that have some semantics that we want<br>
to adapt to. So we must find a good middle spot where you don't have<br>
to configure how it all works and also you get to configure how you<br>
want to use it, somehow.<br></blockquote><div>In my limited experience, it's either "run them all", "run all failing", or run one specific test. <br>But still I think it's best if the UI is as separated from the provider as possible. <br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Hope that helped!<br>
<div class="HOEnZb"><div class="h5">Aleix<br></div></div></blockquote><div>Sure, thanks!<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="HOEnZb">
<div class="h5">
<br>
--<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div><br>