reverse engineering the input needed for full coverage of the program

david2008 has asked for the wisdom of the Perl Monks concerning the following question:

Hi all,
Let's say i have a function(just example)

sub foo{
  my ($a, $b) = @_;
  if($a<0) {
   return 1;
  }
  else {
          if($b>10) {
              return 2;
          }
          else {
              return 3;
          }
  }
}
[download]

the complete values to test the function are
a<0
a>=0,b<=10
a>=0, b>10
How can i analyze the program and get these values automatically?
Thanks,
David

Comment on reverse engineering the input needed for full coverage of the program Download Code

Replies are listed 'Best First'.
Re: reverse engineering the input needed for full coverage of the program by Anonymous Monk on Feb 26, 2014 at 09:42 UTC
How can i analyze the program and get these values automatically? Without looking too hard, Memoize-it to get them by running the function, or through "static" analysis with PPI because since Perl::Critic::Policy is xpaths paste your program into wxPPIxregexplain.pl	[reply]
Re: reverse engineering the input needed for full coverage of the program by locked_user sundialsvc4 (Abbot) on Feb 26, 2014 at 15:53 UTC
This is a specific example of code coverage analysis, or “test coverage analysis,” and it is, as you will see, a relatively big topic. Most commonly, the approach that is taken is to start with test-cases and to seek to analyze in an automatic or computer-assisted fashion which portions of the code are, and are not, covered by those cases. While this is more or less the reverse of the approach that you are looking for, it is also a much more solveable problem in the general case. Also, it tends to be more useful. A system of conditional-tests is in effect a (not-necessarily binary) tree, which of course can produce a frighteningly-large number of unique possibilities, not all of which will be meaningful. (It also cannot mechanically consider the overall context in which the piece of source-code under test might be encountered ... a critical factor which might be an NP-complete [unsolvable ...] problem or nearly so.) Understanding of a real-world program ordinarily involves a level of semantic (i.e. “human”) understanding and guidance that cannot be truly eliminated, hence the approach that starts with tests and then evaluates those tests. But testing-gap analysis can be done, and in a critical software system must be done.