Re: Automated Path Coverage Test Case Generation

I can imagine two ways for this, one easy and one hard:

The easy way would be to write a rudimentary parser that recognizes subroutines, be they methods or plain functions, and within those, recognizes loops and conditionals. For every loop and conditional, it generates mock up code that has possibly to be modified by a human to exercize the boundaries/alternatives.

The hard way is to have a parser for the language to find out what the procedures/methods and conditionals and loops are. Then you can also apply some heuristics to generate from a "known good" test case the negated test case to test for some opposite.

But I would go with the simple approach of automatically generating skeleton tests that reference back to the original code and have these manually fixed by a human.

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web
[download]

Comment on Re: Automated Path Coverage Test Case Generation Download Code

Replies are listed 'Best First'.
Re: Re: Automated Path Coverage Test Case Generation by ChrisS (Monk) on Oct 06, 2003 at 14:05 UTC
If I were to try the easy route, should I use some of the Template modules to build the mock-ups? The hard way would be the more desirable result, but much more complicated. Thanks for the ideas.	[reply]
Re: Re: Re: Automated Path Coverage Test Case Generation by Corion (Patriarch) on Oct 06, 2003 at 14:21 UTC
Using any templating system is an idea that escaped me until you mentioned it, but yes, using a (simple) templating system like HTML::Template is a good idea, as it allows you to also easily output "relevant" metadata without having to change your code. Another bit halfway between the easy and the hard solution is to use Acme::Test (respectively a close relative of it) to generate the skeleton tests, as it already does the gruntwork necessary for the upper level of the test skeleton (would that be the skin?). If you combine that approach with a templating system, you can already have the templates for loop and conditionals testing in place, even if your parser does not yet produce the data structures for these. Another thing is that the templating systems also allow for easy generation of the multiple permutations for loops and conditionals. One thing that might be a downside of HTML::Template is, that it dosen't allow for one template going out into several files, but you can still split up the string generated by it into several strings and use them as separate files. `perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ; # The $d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider ($c = $d->accept())->get_request(); $c->send_response( new #in the HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' # web` [download]	[reply] [d/l]