[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: test program one-shot initialization
On Mon, May 3, 2010 at 11:38 AM, Stathis Kamperis
> Hey everybody,
> Is there a way to add initialization code to my tests cases? Say for
> instance that I want to seed my random number generator, before
> running any test cases.
> Something similar to ATF_TC_CLEANUP(tcX, tc) but for initialization.
cleanup is separate from the body to allow the framework to always
execute cleanup regardless of how the test ended. For example:
supposed you have a test case that starts by loading a kernel module
and halfway through its execution, the test fails. Such kernel module
would remain loaded and cause failures in further tests (or just leave
your system in a state that didn't have before). In this case, you'd
write your cleanup routine (which is tied to a specific test case!) to
unload such module unconditionally. Actually, this is exactly what
the tests in tests/modules do :-)
As for initialization code, you can just put it right into the body.
Why would you split it? Is it there any condition in which you may
want to run the initialization by itself (other than to share the code
across test cases, but that's a separate story)?
> Also, is there a way to do it on a per-test program basis ? E.g.,
> /* Add test cases to test program */
> /* Is it safe to add per-test program initialization code here ? */
Not really. This function is supposed to initialize your test
program. It will be called every time you run the test program even
if it is just to query its test cases (in which case you do not need
any initialization). atf-run currently (in mainline, not in any
public release yet) runs your program with -l first to inspect what
test cases are available and then runs the test cases themselves.
Note the two-pass mentioned above. While you could put some
initialization code in there, it will have nasty side-effects.
My suggestion is: define a global init() function in your .c file that
you call as the very first thing in each test case body. (Or, if you
were using the C++ binding, which I don't currently recommend, you'd
define a top abstract class with common code from which to derive your
individual test cases.)
Main Index |
Thread Index |