[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