[TIP] getting the result of a test in teardown_method?

holger krekel holger at merlinux.eu
Wed May 12 01:19:24 PDT 2010


On Tue, May 11, 2010 at 15:11 -0700, Hans Sebastian wrote:
> Holger,
> 
> Yes, a test result i mean an exception is raised or not.
> 
> There was a case where a helper function which i call in the test and in
> teardown fails for example
> 
> class TestProduct:
>   def test_product(self):
>     # test logic
>     helper.reboot()
> 
>   def teardown_method()
>     # clean up
>     helper.reboot()
> 
> If reboot fails, i don't want to call it again in teardown because it might
> put the product in a different state. That's one example I had.

Hum, could you have your helper guard itself against double-called reboot? 

> Now I just want to measure the time a test takes for each test that passes,
> specifically get the timedelta between when the test started and when it
> ended. I can try your solution iwht the post-check function. However I
> notice pytest_runtest_teardown gets called before my method and class
> teardowns so the teardown won't get measured.

Indeed, the post-check was meant for a checking post-conditions not for timing.
Recording timing for "teardown" executions goes a bit against the grain of 
general setup/call/teardown testing concepts and, for one, py.test will only 
report on setup or teardown calls if there were failures.  We can hack 
a bit around it, see the attached conftest.py which will report timings
for test calls and teardowns at the end of a test run.  You could
also write timings to a file or database instead of reporting to terminal,
of course. 

> Any feedback on better ways on what I am trying to do is welcomed. thanks.

I recommend to try not regard setup/teardown logic as part of a
test and design your tests so that only the actual test call and its
timing is relevant.  If you want to have a time measurement for a full
setup/teardown cycle maybe you move that into its own test and measure that? 

Moreover, you may have more control and simplify test writing 
if you look into using funcargs, there was an example i worked out
in response to Simon Callan which you might find instructive: 
http://codespeak.net/pipermail/py-dev/2010q2/001486.html

I am pretty sure we could extend this example with recording timings. 

best, 
holger




More information about the testing-in-python mailing list