Unit Test integration, another GSoC proposal

Hey,

As the title says I think it would be great to have unit
testing support in 
kdevelop 4 + I want to implement it 

Some goals:
* Generic, both in terms of supported frameworks as well as
languages. 
Obviously QtUnit would be first citizen but pyUnit, CppUnit
& jUnit should be 
supported as well, or at least anticipated
* Running a test should be as simple as clicking a button.
cfr the 
zeroconfiguration in the eclipse jUnit runner
* Generally make kdevelop the state of the art in unit
testing support )


Is this functionality wanted? Does it stand a chance as a
GSoC proposal? Is it 
too ambitious or the contrary?


cheers,
Manuel

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Friday 29 February 2008 03:24:22 pm Manuel Breugelmans
wrote:
> Hey,
>
> As the title says I think it would be great to have
unit testing support in
> kdevelop 4 + I want to implement it 
>
> Some goals:
> * Generic, both in terms of supported frameworks as
well as languages.
> Obviously QtUnit would be first citizen but pyUnit,
CppUnit & jUnit should
> be supported as well, or at least anticipated
> * Running a test should be as simple as clicking a
button. cfr the
> zeroconfiguration in the eclipse jUnit runner
> * Generally make kdevelop the state of the art in unit
testing support )
>
>
> Is this functionality wanted? Does it stand a chance as
a GSoC proposal? Is
> it too ambitious or the contrary?
>
>
> cheers,
> Manuel

Go for it. Projects will be chosen based on how good their
proposals are, so
feel free to ask questions as you write your proposal
--
Matt


_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Saturday 01 March 2008 01:19:16 Matt Rogers wrote:
>
> Go for it. Projects will be chosen based on how good
their proposals are,
> so feel free to ask questions as you write your
proposal
> --
> Matt

I compiled a kdevelop4 and ran the auto-tests  Since
there's currently c++ 
support I suppose frameworks of other languages will have to
wait. Is there a 
feature planning available?

With this in mind I would integrate 
- QtUnit
- CppUnit
- Check

Before writing out my full proposal I'd like to get your
input on 
functionality. This is what I had in mind:
- Graphical runner, selectable execution of tests
- Stub creation
- Link to source in case of failure
- (semi-) self configuring cfr junit eclipse
- Chronological, aggregated reports


- Manuel

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 12.03.08 10:59:55, Manuel Breugelmans wrote:
> On Saturday 01 March 2008 01:19:16 Matt Rogers wrote:
> >
> > Go for it. Projects will be chosen based on how
good their proposals are,
> > so feel free to ask questions as you write your
proposal
> > --
> > Matt
> 
> I compiled a kdevelop4 and ran the auto-tests  Since
there's currently c++ 
> support I suppose frameworks of other languages will
have to wait. Is there a 
> feature planning available?

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)
 
> Before writing out my full proposal I'd like to get
your input on 
> functionality. This is what I had in mind:
> - Graphical runner, selectable execution of tests

This should integrate with the (existing, but probably still
very basic)
run interface we have currently.

> - Stub creation

For this you might want to port the filecreate plugin from
kdevelop3.

> - (semi-) self configuring cfr junit eclipse

Thats really a good idea, we really need more
auto-configuration in
KDevelop.

So, to conclude, I think the given points can make up enough
work for a
GSoC project. Especially getting a good design on the report
view that
makes it usable from future plugins that support other
testing
frameworks.

Andreas

-- 
It is so very hard to be an
on-your-own-take-care-of-yourself-because-there-is-no-one-el
se-to-do-it-for-you
grown-up.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 12 March 2008 07:05:44 Andreas Pakulat wrote:
> On 12.03.08 10:59:55, Manuel Breugelmans wrote:
> > On Saturday 01 March 2008 01:19:16 Matt Rogers
wrote:
> > > Go for it. Projects will be chosen based on
how good their proposals
> > > are, so feel free to ask questions as you
write your proposal
> > > --
> > > Matt
> >
> > I compiled a kdevelop4 and ran the auto-tests  Since
there's currently
> > c++ support I suppose frameworks of other
languages will have to wait. Is
> > there a feature planning available?
>
> 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)
>
> > Before writing out my full proposal I'd like to
get your input on
> > functionality. This is what I had in mind:
> > - Graphical runner, selectable execution of tests
>
> This should integrate with the (existing, but probably
still very basic)
> run interface we have currently.
>
> > - 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.

> > - (semi-) self configuring cfr junit eclipse
>
> Thats really a good idea, we really need more
auto-configuration in
> KDevelop.
>
> So, to conclude, I think the given points can make up
enough work for a
> GSoC project. Especially getting a good design on the
report view that
> makes it usable from future plugins that support other
testing
> frameworks.
>
> Andreas

Thanks
--
Matt

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 12.03.08 07:11:58, Matt Rogers wrote:
> On Wednesday 12 March 2008 07:05:44 Andreas Pakulat
wrote:
> > On 12.03.08 10:59:55, Manuel Breugelmans wrote:
> > > On Saturday 01 March 2008 01:19:16 Matt
Rogers wrote:
> > > > Go for it. Projects will be chosen based
on how good their proposals
> > > > are, so feel free to ask questions as
you write your proposal
> > > > --
> > > > Matt
> > >
> > > I compiled a kdevelop4 and ran the auto-tests
 Since
there's currently
> > > c++ support I suppose frameworks of other
languages will have to wait. Is
> > > there a feature planning available?
> >
> > 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)
> >
> > > Before writing out my full proposal I'd like
to get your input on
> > > functionality. This is what I had in mind:
> > > - Graphical runner, selectable execution of
tests
> >
> > This should integrate with the (existing, but
probably still very basic)
> > run interface we have currently.
> >
> > > - 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.

Andreas

-- 
Your ignorance cramps my conversation.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

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

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 15.03.08 01:31:59, Manu Breugel wrote:
> I've written a draft proposal which can be viewed  at
> http:
//fenix.cmi.ua.ac.be/~p035120/gsoc-0.1.txt
> 
> wadayathink? parts that need more elaboration?

Something that always helps in getting picked for SoC is
having a more
concrete idea about what has to be done and how long each
step might
take. Something like 4 weeks for creating a test-running
framework, 2
weeks for creating a test-stub-creation framework - that
kind of stuff.
It also helps people that look at the proposal to decide
wether they
think the amount of suggested work is too little, too much
or just about
right for the given time-frame.

Andreas

-- 
Don't you feel more like you do now than you did when you
came in?

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Saturday 15 March 2008 02:09:35 Andreas Pakulat wrote:
> On 15.03.08 01:31:59, Manu Breugel wrote:
> > I've written a draft proposal which can be viewed 
at
> > http:
//fenix.cmi.ua.ac.be/~p035120/gsoc-0.1.txt
> >
> > wadayathink? parts that need more elaboration?
>
> Something that always helps in getting picked for SoC
is having a more
> concrete idea about what has to be done and how long
each step might
> take. Something like 4 weeks for creating a
test-running framework, 2
> weeks for creating a test-stub-creation framework -
that kind of stuff.
> It also helps people that look at the proposal to
decide wether they
> think the amount of suggested work is too little, too
much or just about
> right for the given time-frame.
>
> Andreas

I've contacted the QxRunner author to check if his library
is reusable -> 
http://qxrunner.systest.c
h/ 

Depending on this a substantial amount of work could be
saved, so my planning 
will have to wait a little.

I find it hard to guess the amount of effort required for
the self-configuring 
bussiness. Since parts of it might be useful for kdevelop4
in other areas a 
more generic approach seems ok.

Ideally writing a test should go like this:
1. Create stub through template wizard
2. Implement test cases
3. Click run button
4. Show test run result [error in case of compilation
problem]

Ie autobuild. However I dont know enough yet about the
kdevelop4 internals, so 
I'm asking: Is this do-able within a reasonable timespan?


  - Manuel

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel