Ovid,
Well, you can't, with Test::Unit::TestCase, override set_up() and tear_down() from the test code itself, strictly speaking. set_up() is executed before the test code is executed, so at the beginning of the test code you could undo the work that was done in set_up or do more set_up work. Similarly for tearing down fixture, you could do some initial parts of the tear_down work in the test code, but you can't change what will happen in the tear_down method itself; it will always be executed after the test code (as long as set_up() executed successfully).
Putting teardown code in the test itself is a bad idea because if the test fails, that teardown code will not get executed. The Test::Unit framework guarantees that tear_down() will get executed no matter what happens in the test code itself. So the tested code could throw an uncaught exception or die and tear_down() would still get executed.
One of the requirements of unit testing is to isolate fixture setup and teardown from the actual code being tested. This is needed for accurate reporting of the source of errors and to effectively isolate multiple tests from one another.
You asked for an example. You are testing code whose behavior varies depending on the presence or absence of a file (a semphore). You have one test that expects it to be there, and most of the rest expect it not to be. So you need for this one test to create the semphore file during set up and then delete the file during tear down. Putting the code to create and delete the sempahore file inside the test code itself has the following drawbacks:
- If creating the semphore file fails then the feedback you get will indicate that the test had an error in it, rather than that the setup for the test failed
- Similarly, if deleting the sempahore file failes then the feedback will say the test had an error, not that the tear down process had an error.
- Most importantly, if the test code itself fails, then the sempahore will not be removed, breaking the isolation between this test and the ones that are executed after it. You could avoid this by putting the test code in a try block and the tear down code in a finally block, but then you are reinventing the wheel, since tear_dow() is already isolated in this way from the testing code, plus you would have to be careful to rethrow whatever exceptoins were raised by the test code so that it's errors would be properly reported.
Putting this code in a place where it will be executed as part of set_up() and tear_down(), as my extensions do, will allow errors in the set up and tear down to be properly reported as setup/teardown errors and ensures
without extra work in the test code that the teardown will always happen whether the test code succeeds or not.
--DrWhy
"If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."
| [reply] |
You have some excellent points. This, incidentally, is one of the reasons why I was never happy that xUnit style tests end on the first assertion failure within an individual test. With Test::More, those individual assertions are called "tests" and they don't stop running should one test fail. Of course, that does mean it's more likely that one will have a cascading series of failures with possibly unpredictable results.
What I typically do is have code at the top of the test which sets up my environment (not ENV) and if I really need custom cleanup code, I can just set a callback for the &teardown. Still, it sounds like your method might be a bit more natural than what I am used to doing.
| [reply] |
