Test Execution [was: Re: Kdevelop4 gsoc]

Vladimir Prus ghost at cs.msu.su
Sun May 11 15:07:17 UTC 2008


On Sunday 11 May 2008 18:49:56 Manuel Breugelmans wrote:
> On Sunday 11 May 2008 16:10:46 Vladimir Prus wrote:
> > On Sunday 11 May 2008 16:29:46 Manuel Breugelmans wrote:
> > > (typically a method, or an instantiation with data). Right now only the
> > > second is supported by QxRunner, but you'll want to run a testcase in one
> > > go to preserve the shared fixture (eg through initTestCase). Might be a
> > > little tricky with the limited interface of exe's as opposed to full
> > > blown objects.
> > >
> > > An interesting extra feature is auto-backtrace information on hard
> > > errors. Since Kdevelop has strong gdb support this is doable?
> >
> > I don't quite understand what you mean. Can you clarify?
> >
> 
> The idea is to provide a gdb bactrace as the test failure message 
> when one of the test-executables crashes with eg a segmentation fault. The 
> logical step after a test crash is debugging, why not immediatly give this 
> information? A backtrace with jump-to-source functionality might suffice to 
> spot the culprit anyway. 

It might be best to just let (or force) the tests to produce core files, and
add a way to open a core file in debugger straight from whatever widgets shows
the result of the test.

Getting just backtrace will be somewhat awkward in that:
1. You need a debugger to get them
2. A backtrace, as opposed to core file, does not give you a way to
know values of variables.
So it's not obvious why you would not just stop on segfault in the first place.

Even with core files -- does user actually want to run 50 tests, watch 25 of them
segfault, and only then decide to debug one of them?

- Volodya




More information about the KDevelop-devel mailing list