Unit testing (once again)

[Aleix Pol]

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. 

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. 


Hi!
I'm happy to see this development taking shape! Kudos! :)
Regarding "the target explosion" case. I think that the best is to consider by 
yourself how would you like it to be and if you'd like anything to change. 
We're the developers of all these things, so we have the ability to change 
them :).
That is, maybe we want to visually filter these items in the launchers list or 
maybe these shouldn't be stored locally.
For the moment just use what you think makes sense and we'll iterate further.
Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120216/7e2ebe21/attachment.html>