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.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.