[TIP] why do you use py.test?

Florian Leitner florian.leitner at gmail.com
Tue Feb 15 00:27:44 PST 2011


On Feb 15, 2011, at 07:48 , Ronny Pfannschmidt wrote:

> On Tue, 2011-02-15 at 10:12 +0900, Herman Sheremetyev wrote:
>> Hey everyone,
>> 
>> I've seen a lot of messages on this list of people mentioning they use
>> py.test, so I'm curious what advantages it offers. I gave it a try and
>> immediately noticed it was literally 10x slower than nose, taking 0.60
>> seconds to run the same set of tests it takes nose 0.062. As a result
>> I pretty much wrote it off since test speed is pretty important to me,
>> and all the red in my terminal seemed a bit unnecessary. But as I see
>> people continuously mention it I wonder if I missed something about
>> py.test's functionality that could be really useful and offset the
>> speed problems.
>> 
>> So, what are your reasons for using py.test (or some other test runner) ? :)
> 
> My main reasons to use it are funcargs, test generators (not yield
> tests) and local plugins.
> 
> Also all the pylib utilities also come in handy
> (python3 compat, py.path, ...)
> 
> (btw, i specifically switched to it when funcargs and test_generators
> emerged)
> 
> It's pretty much the only python test framework that meets *my* needs
> and wants.
> 
> -- Ronny
> 
>> 
>> -Herman
>> 
>> P.S. I know people tend to get sensitive about their tools, so I don't
>> want to start a flame war, just genuinely curious why people are using
>> this particular one..

My reasons for using py.test are pretty much the same as Ronny's, too. Maybe I'd add that, because of the funcargs, you can actually create a library of scenarios to use in parameterized testing (see Holger's own blog entry on param. testing [1]) and write your test library using inheritance patterns, while your actual code follows composition patterns [2]. I am sure you could do that with nose, too, but this approach is really straightforward with py.test.

Many of my test cases run with both nose and py.test, while I mark tests not working with nose as @nottest. If I compare the performance of the two (nose & py.test) on the ones they both can run, I must say I do not notice the difference you report (a factor of 10). Maybe py.test is slower, not sure, but if it is, for me there is no sufficiently significant difference in there that would let me choose based purely on speed; and with xdist py.test supports distributed testing once this might get an issue, anyways.

Another (minor) factor is the ability to integrate tests into your distribution (py.test --genscript=runtests.py), to create a standalone version of py.test.

You might also want to look at [3], where Holger (et alii :)) explains some of the differences between nose and py.test.

--Florian

[1] http://tetamap.wordpress.com/2009/05/13/parametrizing-python-tests-generalized/
[2] https://github.com/raganwald/homoiconic/blob/master/2010/12/oop.md#readme
[3] http://pytest.org/faq.html


More information about the testing-in-python mailing list