Unit testing (once again)

Miha Čančula miha at noughmad.eu
Thu Feb 23 08:09:28 UTC 2012


2012/2/21 Davide Simoncelli <netcelli.tux at gmail.com>

> Hi Miha,
>
> I was working on PHPUnint plugin for KDevelop but unfortunately I have
> no time to work on it because of my thesis.
> Btw I was able to get testcases and testsuites from both PHP files and
> from PHPUnit xml configuration file that is used to declare custom
> suites. You can find it here:
>
> http://quickgit.kde.org/index.php?p=scratch%2Fdavidesimoncelli%2Fkdev-phpunit.git&a=tree
> I hope it helps.
>
Ooh, great :)

I managed to re-implement finding the test declarations (because I didn't
know about this), but didn't even start on running them. Thanks!

>
> Bye
>
> - Davide
>
>
> PS: You are doing a great work job!
>
> On Fri, Feb 10, 2012 at 10:11 PM, Miha Čančula <miha at noughmad.eu> wrote:
> > 2012/2/10 Andreas Pakulat <apaku at gmx.de>
> >>
> >> On 10.02.12 12:16:26, Milian Wolff wrote:
> >> > On Thursday 09 February 2012 21:59:01 Miha Čančula wrote:
> >> > > Yes, a plugin that implements ITestController can be set as required
> >> > > in the
> >> > > desktop file, that's what I just did. Having more than one
> >> > > implementation
> >> > > for something as basic as holding the list of tests doesn't seem
> >> > > likely.
> >> > >
> >> > > 2012/2/9 David Nolden <zwabel at googlemail.com>
> >> > >
> >> > > > I think this stuff should go into the project toolview, together
> >> > > > with some
> >> > > > proper filtering capabilities. We've already got far too many
> >> > > > toolviews,
> >> > > > they are a usability-mess.
> >> > > >
> >> > > > The project-view could have some filtering-tabs or dropdown at the
> >> > > > top
> >> > > > with items like:
> >> > > > * All
> >> > > > * Sources
> >> > > > * Changed (Replacement for VCS changes view)
> >> > > > * Tests
> >> > > >
> >> > > > Together with some nice color-annotations and maybe
> >> > > > context-sensitive
> >> > > > toolbuttons.
> >> > > >
> >> > > > I think it's time to consolidate what we have.
> >> > > >
> >> > > > Greetings, David
> >> > >
> >> > > I tend to agree with this, since tests will only belong to opened
> >> > > projects.
> >> > > If project managers are to be responsible for finding the test, why
> >> > > separate them afterwards? However, it does require more internal
> >> > > changes,
> >> > > so I won't go ahead without a consensus.
> >> >
> >> > As I said, this is not true. PHP unit tests - and most probably many
> >> > other
> >> > types of unit tests - require language knowledge and hence are *not*
> in
> >> > the
> >> > domain of a project manager.
> >>
> >> Writing unit-tests and potentially interpreting the result indeed
> >> requires language-knowledge. But executing them probably doesn't, or
> >> only very little. For example CTest tests can be using any
> >> unit-test-framework for C, C++ even PHP if you want to use it for that.
> >> Finding these tests is ctest-specific as is executing them. The results
> >> may again require knowledge about the specific unit-test framework.
> >>
> >> So I think tests should simply be done separately from both, but use the
> >> interfaces that projectmanager and language support provide depending on
> >> what the framework and plugins want to support.
> >>
> >> Andreas
> >
> > 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?
> >>
> >>
> >>
> >> --
> >> KDevelop-devel mailing list
> >> KDevelop-devel at kdevelop.org
> >> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
> >
> >
> >
> > --
> > KDevelop-devel mailing list
> > KDevelop-devel at kdevelop.org
> > https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
> >
>
> --
> 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/20120223/76d5f9a6/attachment.html>


More information about the KDevelop-devel mailing list