Re: Testing frysk.testbed.Funit*

[Andrew Cagney <cagney@redhat.com>]

Mark Wielaard wrote:
> Hi Andrew,
>
> On Mon, 2007-07-30 at 11:47 -0400, Andrew Cagney wrote:
>   
>> I'm looking at ways to more directly test the frysk.testbed.Funit* 
>> classes (e.g., FunitExec, DetachedAckProcess) that wrap 
>> PKGLIBDIR/funit-* utilities, but am finding that the most effective 
>> route is to use frysk.proc's framework - duplicating the existing 
>> frysk.proc tests exercising frysk.proc functionality that is effectively 
>> testing that code.
>>
>> I could duplicate the tests but it seems redundant.  Any thoughts on a 
>> strategy?
>>     
>
>   
Mark,

you describe the current state of play; frysk.proc code is testing both 
itself internally and the funit tools implicitly.  There's nothing 
directly testing units such as FunitExecOffspring; instead it is done 
implicitly via frysk.proc.  That is great when it works, but not so 
great when tests fail as differentiating between an FunitExecOffspring 
or frysk.proc breakage that caused the fail isn't possible.

As a contrasting example.  Say we find the UI is crashing and track it 
down to a dwarf binding bug.  What we do is add a test-case to the dwarf 
bindings testing the problem (which contains the root cause of the 
problem); and then fix it.  Is the core code is now being tested, we're 
confident that our problem won't return.  Is there an effective way to 
do that here with the Funit* bindings?

Andrew

> I might be missing the exact cases you want to test. But can't you just
> audit the current frysk.proc tests to see if they cover all relevant
> cases already and if not add one or two tests to the existing proc tests
> so all cases are covered? That way you will also extend the real proc
> tests to handle more cases catching two birds with one stone (if that
> isn't a terribly political incorrect saying).
>
> Cheers,
>
> Mark
>