[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:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
#!/usr/bin/perl
use warnings FATAL => 'all';
use strict;
#
# 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 verif