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

holger krekel holger at merlinux.eu
Wed May 12 01:23:40 PDT 2010


bah ... actually attaching the timing conftest.py now ... 
just put it into a directory with some tests and run the tests, 
it should display something like this at the end: 

    <ItemTestReport 'test_hello' when='call' outcome 'passed'>: 0.30 / 0.20

which indicates call/teardown timings. 
    
H.

On Wed, May 12, 2010 at 10:19 +0200, holger krekel wrote:
> 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
> 

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: conftest.py
Type: text/x-python
Size: 1024 bytes
Desc: not available
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20100512/2eef0ac4/attachment.py>


More information about the testing-in-python mailing list