Unit testing (once again)

[Davide Simoncelli]

Hi Miha,

I was working on PHPUnint plugin for KDevelop but unfortunately I have
no time to work on it because of my thesis.
Btw I was able to get testcases and testsuites from both PHP files and
from PHPUnit xml configuration file that is used to declare custom
suites. You can find it here:
http://quickgit.kde.org/index.php?p=scratch%2Fdavidesimoncelli%2Fkdev-phpunit.git&a=tree
I hope it helps.

Bye

- Davide


PS: You are doing a great work job!

On Fri, Feb 10, 2012 at 10:11 PM, Miha Čančula <miha at noughmad.eu> wrote:
> 2012/2/10 Andreas Pakulat <apaku at gmx.de>
>>
>> On 10.02.12 12:16:26, Milian Wolff wrote:
>> > On Thursday 09 February 2012 21:59:01 Miha Čančula wrote:
>> > > Yes, a plugin that implements ITestController can be set as required
>> > > in the
>> > > desktop file, that's what I just did. Having more than one
>> > > implementation
>> > > for something as basic as holding the list of tests doesn't seem
>> > > likely.
>> > >
>> > > 2012/2/9 David Nolden <zwabel at googlemail.com>
>> > >
>> > > > I think this stuff should go into the project toolview, together
>> > > > with some
>> > > > proper filtering capabilities. We've already got far too many
>> > > > toolviews,
>> > > > they are a usability-mess.
>> > > >
>> > > > The project-view could have some filtering-tabs or dropdown at the
>> > > > top
>> > > > with items like:
>> > > > * All
>> > > > * Sources
>> > > > * Changed (Replacement for VCS changes view)
>> > > > * Tests
>> > > >
>> > > > Together with some nice color-annotations and maybe
>> > > > context-sensitive
>> > > > toolbuttons.
>> > > >
>> > > > I think it's time to consolidate what we have.
>> > > >
>> > > > Greetings, David
>> > >
>> > > I tend to agree with this, since tests will only belong to opened
>> > > projects.
>> > > If project managers are to be responsible for finding the test, why
>> > > separate them afterwards? However, it does require more internal
>> > > changes,
>> > > so I won't go ahead without a consensus.
>> >
>> > As I said, this is not true. PHP unit tests - and most probably many
>> > other
>> > types of unit tests - require language knowledge and hence are *not* in
>> > the
>> > domain of a project manager.
>>
>> Writing unit-tests and potentially interpreting the result indeed
>> requires language-knowledge. But executing them probably doesn't, or
>> only very little. For example CTest tests can be using any
>> unit-test-framework for C, C++ even PHP if you want to use it for that.
>> Finding these tests is ctest-specific as is executing them. The results
>> may again require knowledge about the specific unit-test framework.
>>
>> So I think tests should simply be done separately from both, but use the
>> interfaces that projectmanager and language support provide depending on
>> what the framework and plugins want to support.
>>
>> Andreas
>
> Ok, here are some results. The platform parts (interfaces, a controller, and
> a toolview) are in the unittest branch of kdevplatform. If you wish I can
> post a review request tomorrow. I have attached a sample screenshot, the
> icons may not be the best choice, but it shows the system is working.
>
> I have implemented a quick test finder in
> CMakeProjectVisitor::visit(AddTestAst*), but that seems a little hackish to
> me. I would prefer to have a separate plugin for it, then have the cmake
> project manager call it. So I don't think I have any code in KDevelop worth
> sharing right now. Besides, there is no code for running the tests (see
> below). I'm not really familiar with PHP, so I haven't delved into its
> parsing code just yet, but I plan to do it soon.
>
> Regarding the interface, I went with the approach suggested by Milian (a
> central ITestController that holds a list of ITestSuite's). A TestSuite has
> a name, an url and a list of test cases, and a separate controller would
> make it easy to push it into the project model if desired. The tree
> structure is made entirely in the view with the fixed three-layer model, as
> can be seen by the different icons.
>
> However I do have questions about running the tests, especially about using
> ILaunchConfiguration. So far those methods are still unimplemented. It's
> logical that different implementations launch their tests and parse the
> output for results in different ways. So would every plugin have to provide
> a LaunchConfigurationType as well as an ILauncher? Or is there something
> else it should do? Most importantly, is it a even good thing to be using it?
>>
>>
>>
>> --
>> KDevelop-devel mailing list
>> KDevelop-devel at kdevelop.org
>> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
>
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>