<div class="gmail_quote">2012/2/21 Davide Simoncelli <span dir="ltr"><<a href="mailto:netcelli.tux@gmail.com" target="_blank">netcelli.tux@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Miha,<br>
<br>
I was working on PHPUnint plugin for KDevelop but unfortunately I have<br>
no time to work on it because of my thesis.<br>
Btw I was able to get testcases and testsuites from both PHP files and<br>
from PHPUnit xml configuration file that is used to declare custom<br>
suites. You can find it here:<br>
<a href="http://quickgit.kde.org/index.php?p=scratch%2Fdavidesimoncelli%2Fkdev-phpunit.git&a=tree" target="_blank">http://quickgit.kde.org/index.php?p=scratch%2Fdavidesimoncelli%2Fkdev-phpunit.git&a=tree</a><br>
I hope it helps.<br></blockquote><div>Ooh, great :)<br><br>I managed to re-implement finding the test declarations (because I didn't know about this), but didn't even start on running them. 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">
<br>
Bye<br>
<span><font color="#888888"><br>
- Davide<br>
</font></span><br>
<br>
PS: You are doing a great work job!<br>
<div><div><br>
On Fri, Feb 10, 2012 at 10:11 PM, Miha Čančula <<a href="mailto:miha@noughmad.eu" target="_blank">miha@noughmad.eu</a>> wrote:<br>
> 2012/2/10 Andreas Pakulat <<a href="mailto:apaku@gmx.de" target="_blank">apaku@gmx.de</a>><br>
>><br>
>> On 10.02.12 12:16:26, Milian Wolff wrote:<br>
>> > On Thursday 09 February 2012 21:59:01 Miha Čančula wrote:<br>
>> > > Yes, a plugin that implements ITestController can be set as required<br>
>> > > in the<br>
>> > > desktop file, that's what I just did. Having more than one<br>
>> > > implementation<br>
>> > > for something as basic as holding the list of tests doesn't seem<br>
>> > > likely.<br>
>> > ><br>
>> > > 2012/2/9 David Nolden <<a href="mailto:zwabel@googlemail.com" target="_blank">zwabel@googlemail.com</a>><br>
>> > ><br>
>> > > > I think this stuff should go into the project toolview, together<br>
>> > > > with some<br>
>> > > > proper filtering capabilities. We've already got far too many<br>
>> > > > toolviews,<br>
>> > > > they are a usability-mess.<br>
>> > > ><br>
>> > > > The project-view could have some filtering-tabs or dropdown at the<br>
>> > > > top<br>
>> > > > with items like:<br>
>> > > > * All<br>
>> > > > * Sources<br>
>> > > > * Changed (Replacement for VCS changes view)<br>
>> > > > * Tests<br>
>> > > ><br>
>> > > > Together with some nice color-annotations and maybe<br>
>> > > > context-sensitive<br>
>> > > > toolbuttons.<br>
>> > > ><br>
>> > > > I think it's time to consolidate what we have.<br>
>> > > ><br>
>> > > > Greetings, David<br>
>> > ><br>
>> > > I tend to agree with this, since tests will only belong to opened<br>
>> > > projects.<br>
>> > > If project managers are to be responsible for finding the test, why<br>
>> > > separate them afterwards? However, it does require more internal<br>
>> > > changes,<br>
>> > > so I won't go ahead without a consensus.<br>
>> ><br>
>> > As I said, this is not true. PHP unit tests - and most probably many<br>
>> > other<br>
>> > types of unit tests - require language knowledge and hence are *not* in<br>
>> > the<br>
>> > domain of a project manager.<br>
>><br>
>> Writing unit-tests and potentially interpreting the result indeed<br>
>> requires language-knowledge. But executing them probably doesn't, or<br>
>> only very little. For example CTest tests can be using any<br>
>> unit-test-framework for C, C++ even PHP if you want to use it for that.<br>
>> Finding these tests is ctest-specific as is executing them. The results<br>
>> may again require knowledge about the specific unit-test framework.<br>
>><br>
>> So I think tests should simply be done separately from both, but use the<br>
>> interfaces that projectmanager and language support provide depending on<br>
>> what the framework and plugins want to support.<br>
>><br>
>> Andreas<br>
><br>
> Ok, here are some results. The platform parts (interfaces, a controller, and<br>
> a toolview) are in the unittest branch of kdevplatform. If you wish I can<br>
> post a review request tomorrow. I have attached a sample screenshot, the<br>
> icons may not be the best choice, but it shows the system is working.<br>
><br>
> I have implemented a quick test finder in<br>
> CMakeProjectVisitor::visit(AddTestAst*), but that seems a little hackish to<br>
> me. I would prefer to have a separate plugin for it, then have the cmake<br>
> project manager call it. So I don't think I have any code in KDevelop worth<br>
> sharing right now. Besides, there is no code for running the tests (see<br>
> below). I'm not really familiar with PHP, so I haven't delved into its<br>
> parsing code just yet, but I plan to do it soon.<br>
><br>
> Regarding the interface, I went with the approach suggested by Milian (a<br>
> central ITestController that holds a list of ITestSuite's). A TestSuite has<br>
> a name, an url and a list of test cases, and a separate controller would<br>
> make it easy to push it into the project model if desired. The tree<br>
> structure is made entirely in the view with the fixed three-layer model, as<br>
> can be seen by the different icons.<br>
><br>
> However I do have questions about running the tests, especially about using<br>
> ILaunchConfiguration. So far those methods are still unimplemented. It's<br>
> logical that different implementations launch their tests and parse the<br>
> output for results in different ways. So would every plugin have to provide<br>
> a LaunchConfigurationType as well as an ILauncher? Or is there something<br>
> else it should do? Most importantly, is it a even good thing to be using it?<br>
>><br>
>><br>
>><br>
>> --<br>
>> KDevelop-devel mailing list<br>
>> <a href="mailto:KDevelop-devel@kdevelop.org" target="_blank">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>
><br>
> --<br>
> KDevelop-devel mailing list<br>
> <a href="mailto:KDevelop-devel@kdevelop.org" target="_blank">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>
--<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org" target="_blank">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>