Unit testing (once again)

[Miha Čančula]

2012/2/10 Miha Čančula <miha at noughmad.eu>

> 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?
>

Now I got some more work done, and I have more specific questions as well.
For CTest, I implemented the whole ILaunchConfig-LaunchConfigType-ILauncher
machinery, and it's able to run tests either from the toolview or from the
project view (when right-clicking on an executable target declared as a
test). However, creating LaunchConfigurations has the unwanted effect of
spamming the Run configurations dialog, and storing a large amount of data
in the project config file. For projects like KDev*, this means that Run =>
Current Launch Configuration covers the entire screen.

So I'd ask someone with more experience with the code, is there an easy way
to make a LaunchConfiguration temporary and hidden? I couldn't find any, so
I'm leaning towards a simpler interface like
class ITestSuite {
virtual KJob* runAllCases() const = 0;
}
with similar methods for running specific test cases. This loses some of
the integration (like running from the project view), but that can be
implemented manually. However, it still allows for using the output view
and RunController::registerJob(), so I think nothing of value is lost.

On a more optimistic front, I got around to checking out the PHP plugin and
implementing a PHPUnit test finder for it. As you can see in attached
screenshot, it works. This one only uses the DUChain, which I think is
great because I didn't have to mess with the parser. The running of PHP
tests is not yet implemented, as I'm waiting for some input.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120215/bdf94fff/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdev-test-php.png
Type: image/png
Size: 390873 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120215/bdf94fff/attachment.png>