[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