Unit Test integration, another GSoC proposal

[Manuel Breugelmans]

On Wednesday 12 March 2008 16:42:35 Andreas Pakulat wrote:
> On 12.03.08 07:11:58, Matt Rogers wrote:
> > >
> > > As far as other languages go, Ruby and Python support are probably
> > > going to exist for KDevelop 4.1. Other languages are not planned so
> > > far, so they'll only be done when somebody starts to work on them (a
> > > parser for both Java and C# exists already)
> > >

Neat, especially support for python and pyUnit interests me personally.

> > >
> > > > - Stub creation
> > >
> > > For this you might want to port the filecreate plugin from kdevelop3.
> >
> > No, actually he doesn't. He'll want to use duchain to generate stubs
> > based on another class. The file create plugin from kdevelop 3 is not
> > worth porting, IM HO, not with all the cool duchain stuff that we have.
>
> Well, its still cool to have the "new class" wizard fill in the
> copyright headers for me.
>
> Apart from that, DUChain only helps you to recognize existing code, it
> doesn't help when you want to create a new file for a new class. (Except
> for getting the base class, possibly abstract methods and the right
> #include). So maybe rather port the C++ class wizard to kdevelop4 and
> make it work with duchain, but include the possibility to have a
> template-header and footer file thats used for a new .h or .cpp.
>

I'll definitly look further into this. 

A couple of extra, more exotic features which might not fit in the timeframe. 
If any of those seem more interesting I could swap or prioritize :)

- Test tagging, often you have regression & todo-tests, that are known to 
fail. Making this distinction on the runner level would be interesting.
- Auto use of debugger backtrace information in case of hard errors
- Test coverage reports through gcov
- User defined graph-based run ordering, if the failure of test A is known to 
cause a ripple of other failures you really dont want to be running them 
since this blurs the defect location.


- Manuel