Unit Testing

[Miha Čančula]

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.

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.

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.

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.

>
> > 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
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120515/f25c040b/attachment.html>