[IPython-dev] Fwd: [TIP] py.test 1.0 release / remarks
Fernando Perez
fperez.net at gmail.com
Tue Aug 4 15:45:52 EDT 2009
Howdy,
not that I'm advocating any changes *now*, but this might be worth
looking into. I think nose and py.test share some ancestry, and it
seems that py.test is maturing nicely. I especially like the
'funcargs' way of writing parametric tests without 'yield': I use
parametric tests *a lot*, but they are extremely hard to debug when
they break, because of how nose runs them.
Just a note for the scratchpad :)
Cheers,
f
---------- Forwarded message ----------
From: holger krekel <holger at merlinux.eu>
Date: Tue, Aug 4, 2009 at 7:43 AM
Subject: [TIP] py.test 1.0 release / remarks
To: Testing in Python <testing-in-python at lists.idyll.org>
Hi testing-in-python,
i am happy to announce the 1.0.0 py.test release:
http://tetamap.wordpress.com/2009/08/04/pylib-1-0-0
the new features are reasonably stable now - let me summarize
a few distinctive ones maybe of interest to people
particularly interested into testing with python:
* test function arguments ("funcargs"): With this, python test
functions can name arguments and one writes factory functions to
provide instances for such arguments. These factory
functions now have many interaction possibilities, for example
they can use helper methods to efficiently manage the life cycle of
such fixture objects across the whole testing process. Test function
arguments also make test parametrization natural - one sinmply provides
several different argument instances, no changes to the test
function needed, no magic "yield" for generating tests anymore -
although 1.0 still allows them and of course also allows
traditional xUnit-style setup or even running unittest.py style tests.
* plugins: it is now easy to write plugins by implementing one
or more of the 37 hooks which py.test calls to implement
the testing process. There are many examples, among them
the "oejskit" plugin which integrates testing of javascript
code in real-life browsers into a regular test run.
Apart from such separately distributed "cross-project" plugins
you can also write per-project plugins/extensions that lives
with your testing code.
* distributed testing: distributing test runs among Linux/OSX/Windows
hosts and across python-2.4 till python-2.6 interpreters
works reasonably stable now. This means that you can easily
iron out test-module/function specific problems across a
variety of platforms, accelerating the change & test feedback cycle.
* xfail: a new way to mark tests as "expected to fail" which
means they run normally but are reported/counted specially.
This "xfail" mark is meant to mark missing / wrong implementation
rather than missing dependencies / wrong platforms for which one
uses "skip". Especially for larger test suites making
this distinction is very helpful.
* IO-capturing: output of test functions is captured per-test,
by default including any output from sub processes.
This works on all platforms and also (now) interacts well
with the logging module without importing/using it itself so
there are no interferences.
* pastebin: sends your test session output or individual test
failures to the Pocoo pastebin service and prints out URLs.
Convenient for seemless IRC/messaging communication.
Hope you find some of this interesting and let the issue tracker,
the mailing list or me know of any issues or comments.
cheers,
holger
--
Metaprogramming, Python, Testing: http://tetamap.wordpress.com
Python, PyPy, pytest contracting: http://merlinux.eu
_______________________________________________
testing-in-python mailing list
testing-in-python at lists.idyll.org
http://lists.idyll.org/listinfo/testing-in-python
More information about the IPython-dev
mailing list