Unit Testing

[Milian Wolff]

On Tuesday 15 May 2012 15:57:04 Miha Čančula wrote:
> 2012/4/30 Milian Wolff <mail at milianw.de>
> 
> > On Sunday 29 April 2012 20:36:44 Miha Čančula wrote:
> > > Alright, we have school holidays this week, so that means some extra
> > > kdevelop time for me. I removed the CTestFinder plugin and merge the
> > > test-finding code to CMakeManager. This means no manual reloading is
> > > needed, and tests are reported in the GUI as soon as they are parsed.
> > 
> > I'll
> > 
> > > try to do the same for PHP tomorrow.
> > 
> > Sounds good, thanks. But sadly I cannot try it out, at least one file is
> > missing in kdevplatform (testcontroller.cpp) - can you please make sure
> > you've
> > committed all files?
> > 
> > Btw have you managed to find a solution to the "lets remove/update changed
> > tests" problem yet?
> 
> Oh, hi. I'm sorry for not replying earlier, I didn't see the mail due to a
> misconfigured Gmail. I found some extra kdevelop time since then, and I
> think I fixed that missing file as well.

Also took me some time to reply here :) But you are up to your knees in the 
GSOC stuff anyways, so I take this more as a general response to anyone 
interested in working on unit testing integration for kdevelop.

> About updating tests: They are updated automatically, whenever the relevant
> files are reparsed. I have not yet testing this, so I'm not sure if it
> works or not. If it doesn't yet, I don't think it takes much effort to make
> it work. I modified the TestController to overwrite the tests by default
> when a new one with the same name and project is registered. There is also
> a difference between changing the CMake file and the source where the test
> class is declared/defined. There is no way yet of knowing when the list of
> test cases is changed.

With test case being a method in a test suite? Or what do you mean here?

> Automatic removal is harder. I paid no attention to it yet, as I think it's
> a lower priority. Note that this includes renamed test suites. The one way
> I imagine this would work is storing a file with every suite, and removing
> all suites from each file as it is reparsed. Personally I think this is too
> much work for the computer, and might be bad for usability if tests
> temporarily disappear because of a missing semicolon in some file. But if
> you think it's beneficial I'll do my best to add it.

Yeah, this needs to be implemented. Having stale stuff showing up in the UI is 
bad. If I create a test suite with a type and rename it, that should be 
handled properly. Just as well, I don't want to hit a dead-end if I remove a 
test suite (or e.g. move it to a different project).

> Another thing I have planned is an option to enable or disable test output.
> This would allow things like Commit Review to run tests and receive reports
> without other toolviews popping up.

Good idea.

> > > I'm still having trouble with a custom Job subclass, especially because
> > 
> > of
> > 
> > > the OutputJob dependency. So I'm thinking it would be better to keep the
> > > current interface (KJob* launchCase() etc. ) and leave result reporting
> > 
> > to
> > 
> > > the ITestController. Except that instead of having a result() method on
> > 
> > the
> > 
> > > TestSuite itself, a TestResult argument to the testRunFinished() signal
> > > could be added.
> > 
> > I can try to have a look at that.
> > 
> > Cheers
-- 
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/20120818/18916d79/attachment.sig>