
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">

<html><head><meta name="qrichtext" content="1" /><style type="text/css">

p, li { white-space: pre-wrap; }

</style></head><body style=" font-family:'Ubuntu'; font-size:9pt; font-weight:400; font-style:normal;">

<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">On Wednesday 15 February 2012 21:04:25 Miha Čančula wrote:<br /></p>

<p style=" margin-top:12px; margin-bottom:0px; margin-left:40px; margin-right:40px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">2012/2/10 Miha Čančula <<a href="mailto:miha@noughmad.eu"><span style=" text-decoration: underline; color:#0057ae;">miha@noughmad.eu</span></a>><br /></p>

<p style=" margin-top:0px; margin-bottom:0px; margin-left:44px; margin-right:40px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">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. <br /><br />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. <br /><br />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. <br /><br />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?<br /></p>

<p style=" margin-top:0px; margin-bottom:0px; margin-left:40px; margin-right:40px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br />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. <br /><br />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<br />class ITestSuite {<br />virtual KJob* runAllCases() const = 0;<br />}<br />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. <br /><br />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. <br /><br /></p>

<p style=" margin-top:0px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Hi!</p>

<p style=" margin-top:0px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">I'm happy to see this development taking shape! Kudos! :)</p>

<p style=" margin-top:0px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">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 :).</p>

<p style=" margin-top:0px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">That is, maybe we want to visually filter these items in the launchers list or maybe these shouldn't be stored locally.</p>

<p style=" margin-top:0px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">For the moment just use what you think makes sense and we'll iterate further.</p>

<p style=" margin-top:0px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Aleix</p></body></html>