Test Compilation [was: Re: Kdevelop4 gsoc]

[Andreas Pakulat]

On 11.05.08 14:29:40, Manuel Breugelmans wrote:
> 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.

You're mixing things a bit here. A "target" in the sense of a
buildsystem is a buildable item, i.e. an executable or shared library
for native apps built from a couple of source files. Running is done by
a different framework, which has the concept of configuration types and
actual launch configurations. As Vladimir already said we should have
custom config types for the various testing framework which know how to
execute a specific testcase. In the case of QtTest a testcase would be a
target-item from the buildsystem which uses the QtTest facilities.

> > > >  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.

Yeah, I think thats the best thing to do, also with the config-type
stuff in mind. So each testing-framework-plugin can contribute its own
config-type.

> 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

I really need to check out the API/code :)

Andreas

-- 
You will be the last person to buy a Chrysler.