Unit testing (once again)

[Miha Čančula]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120210/c9ac1585/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdev-test1.png
Type: image/png
Size: 42345 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120210/c9ac1585/attachment.png>