Test Compilation [was: Re: Kdevelop4 gsoc]

[Manuel Breugelmans]

On Sunday 11 May 2008 09:38:58 Andreas Pakulat wrote:
> On 11.05.08 03:52:42, Aleix wrote:
> > On 5/10/08, Andreas Pakulat <apaku at gmx.de> wrote:
> > > On 06.05.08 21:41:12, Manuel Breugelmans wrote:
> > >  > 2. How to compile the tests, what kind of user input is required
> > >  > here?
> > >  >
> > >  > a/ just let the user wite his own build rules with system of choice
> > >  > b/ automate it for cmake based projects? request only include dir's
> > >  > and libraries/objects to link to.
> > >  >
> > >  > Option a is the easiest implementation wise but not so user
> > >  > friendly. If this route is taken 1. is a non-issue ... Maybe support
> > >  > this first and extend to b/ later.
> > >
> > > Both are needed IMHO. a) can be easy in larger projects such as KDE4
> > >  which already have unit-tests and thus its basically just a one-liner
> > > to add a new test. However if you're not in such a project it would be
> > > nice to use the buildtools. Using the Buildsystem API you can even do
> > > it easily for all buildsystems that kdevelop supports, because you can
> > > just tell the buildsystem to add a new target item with a couple of
> > > sources attached.
> >
> > Well, you already know how I feel about editing user scripts, I don't
> > really think that messing with it is a good idea...
>
> Well, thats why I said both need to be there. People that generally use
> the GUI for their buildsystem will use b), others that know their
> buildsystem will use option a) anyway :)
>
> > But anyway, my point is that you shouldn't do it buildtool dependent,
>
> Exactly my point, use the API we already have:
> BuildSystemManager::createTargetItem()

Probably concepts like 'test-build' and 'test-run' target are needed here, 
next to the conventional build-run-debug. The run target could then either 
depend on test-build one(s) or some form of external specification, the 
exectuables/object code. This auto build can also make some
intelligent decisions such as insertion of gcov related flags.


> > >  One thing I just thought of: Are different testing-tools/API's going
> > > to be different plugins or do you want to encapsulate all in one
> > > plugin? IMHO the former is better, using common widgets and stuff
> > > available from a library (maybe even more than just that), because it
> > > allows to more easily add support later for other testing tools -
> > > specifically using scripting languages. 

Ok I'll split it up in different plugins. The backend for visualizing runner 
progress is generic already with a clean interface so this wont require much 
work. To implement support for a framework you need to:
1. Subclass a RunnerItem and implement the run method
2. Subclass a RunnerModel with specific test registration

Not sure if it's necessary to provide control over the actual widgets used. Is 
there a reason to select different ones between frameworks? You always 
need:

- select cases
- run
- show results
- coupling back to the source (jump to, annotation)


Manuel