Unit testing (once again)

[Milian Wolff]

On Wednesday 15 February 2012 21:04:25 Miha Čančula wrote:
> 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.

You are right, the run configuration of a unit test is nothing the user wants 
to change (or?). Hence hiding them from the config dialog makes sense I think. 
I will have to think about the first statement though, maybe there are some 
tests that need to be launched in a specific way and hence require proper 
configuration...

But regarding a custom job: I think this also has the the advantage of adding 
custom highlighting (e.g. FAIL/XFAIL/XPASS/PASS for QTest).

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

Great, that's already looking very good :)

I will help with reviewing, cleaning up and beautifying in about 2 weeks tops. 
I'll have lots of time again then :)

Cheers and as Aleix said: Kudos for your work here!

Bye

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120216/56e4f677/attachment.sig>