Thanks, I'll try that. It's just that it's likely I'll end up moving stuff from [setup|teardown]_* into other functions which I call manually (or possibly magically) before and after each test, which seems a bit counterproductive.
Matthew On Mon, Aug 11, 2008 at 6:33 PM, Neil Shepperd <[EMAIL PROTECTED]> wrote: > On Mon, 2008-08-11 at 08:17 +1200, Matthew Edwards wrote: > > Hi, > > > > I've got some tests for a module which manages log files. The > > setup_class and teardown_class functions create and delete a directory > > for them, and the teardown_method function deletes the individual > > files based on a list. When a test fails, it can leave files which > > aren't on the list, so don't get deleted in teardown_method, which > > makes teardown_class choke on os.rmdir (because the directory is not > > empty). While I do need to know if there are files left over, the > > problem is that when an exception occurs in a hook, it shows a > > traceback for that only, and not the actual test failure, so I can't > > tell what failed. > If having no files left over is necessary for the test to pass, > that should be part of the test. You should probably use rmtree > in the hook, as hooks are not tests, and must always work - independent > of whether the test itself passes. > > > > Am I just doing this wrong, or is this a bit of a bug? I would prefer > > an exception in [setup|teardown]_method to fail that method, and an > > exception in [setup|teardown]_class to fail all the tests in that > > class > May be a bad idea. IMHO setup/teardown should do just what they're > called - setup and teardown an environment for tests to run in. If > an exception occurs in [setup|teardown]_* it should be because your > setup/teardown code is broken. Mixing up setup/teardown with tests > themselves seems like a mistake to me. > > Neil Shepperd >
_______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
