a new utility: failure tests sequence finder

[Stas Bekman <st...@stason.org>]

[crossposting httpd/modperl test/dev lists, since it's relevant to both]

Intro: When we try to test a stateless machine (i.e. all tests are
independent), running all tests once ensures that all tested things
properly work. However when a state machine is tested
(i.e. where a run of one test may influence another test) it's not
enough to run all the tests once to know that the tested features
actually work. It's quite possible that if the same tests are run in
a different order and/or repeated a few times, some tests may fail.
This usually happens when some tests don't restore the system under
test to its pristine state at the end of the run, which may
influence other tests which rely on the fact that they start on
pristine state, when in fact it's not true anymore. In fact it's
possible that a single test may fail when run twice or three times
in a sequence.

Solution: To reduce the possibility of such dependency errors, it's
important to run random testing repeated many times with many
different srand seeds. Of course if no failures get spotted that
doesn't mean that there are no tests inter-dependencies, which may
cause a failure in production. But random testing definitely helps
to spot many problems and gives better test coverage.

Resolving sequence problems: When this kind of testing is used and a
failure is detected there are two problems:
* First is to be able to reproduce the problem so if we think we fix
   it, we could verify the fix. This one is easy, just remember the
   sequence of tests run till the failed test and rerun the same
   sequence once again after the problem has been fixed.
* Second is to be able to understand the cause of the problem. If
   during the random test the failure has happened after running 400
   tests, how can we possibly know which previously running tests has
   caused to the failure of the test 401. Chances are that most of
   the tests were clean and don't have inter-dependency
   problem. Therefore it'd be very helpful if we could reduce the
   long sequence to a minimum. Preferably 1 or 2 tests. That's when
   we can try to understand the cause of the detected problem.

   This program attempts to solve both problems, and at the end of
   each iteration print a minimal sequence of tests causing to a
   failure. This doesn't always succeed, but works in many cases.

This utility:
1. runs the tests randomly until the first failure is detected.
2. then it tries to reduce that sequence of tests to a minimum, and
    this sequence still causes to the same failure.

X. (XXX: not yet) then it reruns the minimal sequence in the verbose
    mode and saves the output

If the program's first argument is NONSTOP, it will run in a loop
MAX_ITER times or until aborted. On each iteration it will use a
different random seed which potentially should detect different
failures. After each iteration a report is created which is saved
into a file of format: smoke-report-Fri_Dec__7_19:28:57_2001.txt

so if before you went to sleep you were running:
     % t/TEST
now you should run
     % util/smokerandom.pl NONSTOP
from the same directory

the utility is not in cvs yet, so I've attached it here.

_____________________________________________________________________
Stas Bekman             JAm_pH      --   Just Another mod_perl Hacker
http://stason.org/      mod_perl Guide   http://perl.apache.org/guide
mailto:stas@stason.org  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/

Re: a new utility: failure tests sequence finder

[Stas Bekman <st...@stason.org>]

Currently I use a random size windowing algorithm to try to reduce the 
number of tests that cause the problem to a minimum, but I realize that 
it may not work in some cases since it's random. I need your help with 
coming up with a few algorithms to apply to the long sequence of tests 
to effectively and fast reduce it to a minimum.

After the first run, it's possible that the sequence will include 500 
tests. Currently I the algorithm that picks a slice from this sequence 
using random edges. From preliminary testing in some cases it reduces 
500 tests to 2 in just a few runs, but in some cases it just cannot 
reduce at all. It's random after all.

I was thinking to try first something like binary search, but chances 
that it'll work are not big since it's possible that there are two tests 
causing to the failure of the third and they can be located in different 
halves of the sequence. I guess I should try it anyway.

I was think about the password cracker that applies a set of different 
algoritms for each path, and I was thinking to take the same route, to 
improve the efficiency of this utility (after all tests are running very 
slow). But I'm not sure which other algorithms I could try.

So if you have any insights please let me know. Thanks a lot!


_____________________________________________________________________
Stas Bekman             JAm_pH      --   Just Another mod_perl Hacker
http://stason.org/      mod_perl Guide   http://perl.apache.org/guide
mailto:stas@stason.org  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/

Re: a new utility: failure tests sequence finder

[Stas Bekman <st...@stason.org>]

Doug MacEachern wrote:

> concept sounds great, +1
> haven't looked at the code, but i should probably be in a module, like
> Apache::TestSmoke.  that can either be run with -M or a tiny generated
> t/SMOKE (like t/TEST) or from t/TEST.  else each project that wants to use
> it needs a copy of util/smokerandom.pl
> the idea has always been for a project that wants a t/TEST only needs the
> Apache-Test directory.  then they create custom t/conf/foo.conf.in,
> t/foo/*.t and everything else is setup for you.

Sure, that was just a proof of concept, so it was a quick and dirty 
script. I'll do more polishing and put it into a module.

So do you prefer to have t/SMOKE.PL or to add a new t/TEST option 
(what's the mnemonic for -M) or both?

_____________________________________________________________________
Stas Bekman             JAm_pH      --   Just Another mod_perl Hacker
http://stason.org/      mod_perl Guide   http://perl.apache.org/guide
mailto:stas@stason.org  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Re: a new utility: failure tests sequence finder

[Doug MacEachern <do...@covalent.net>]

concept sounds great, +1
haven't looked at the code, but i should probably be in a module, like
Apache::TestSmoke.  that can either be run with -M or a tiny generated
t/SMOKE (like t/TEST) or from t/TEST.  else each project that wants to use
it needs a copy of util/smokerandom.pl
the idea has always been for a project that wants a t/TEST only needs the
Apache-Test directory.  then they create custom t/conf/foo.conf.in,
t/foo/*.t and everything else is setup for you.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Re: a new utility: failure tests sequence finder

[Doug MacEachern <do...@covalent.net>]

concept sounds great, +1
haven't looked at the code, but i should probably be in a module, like
Apache::TestSmoke.  that can either be run with -M or a tiny generated
t/SMOKE (like t/TEST) or from t/TEST.  else each project that wants to use
it needs a copy of util/smokerandom.pl
the idea has always been for a project that wants a t/TEST only needs the
Apache-Test directory.  then they create custom t/conf/foo.conf.in,
t/foo/*.t and everything else is setup for you.