I'll enthusiastically second py.test. It's well documented, well supported, and well thought out. More importantly though, the details are just brilliantly done.

For example: showing the values of local variables in an error traceback always saves me a ton of time. I don't know why this isn't the default option. Alternatively, you can pass --pdb to just run the debugger exactly when a test crashes, so you can inspect the contents.

Another example is how it prints out details on assertions (e.g. "the left was this and the right was this") and not just "AssertionError". On top of that, for complex data structures, it will diff them and point out exactly what parts of the structure are matching and what parts are not matching, which again saves a ton of time from firing up a debugger and doing it by hand.

For more esoteric options, I like this pycon talk: https://www.youtube.com/watch?v=jmsk1QZQEvQ

Pretty much anybody with big modern project i know in the industry is using pytest.

It make the barrier of entry of writting tests much lower. Given how annoying it is to write test, i'd say making it even a tiny bit easier is a win.

Plus fixtures scale better than tearUp and down.

Hmm I'm in the camp that believes setUp/tearDown and fixtures are not only equivalent, but both antipatterns.

This article explains it better than I can [1]

[1] https://robots.thoughtbot.com/lets-not

pytest fixtures don't have that issue, as they're only run when you include the fixture for DI

> pytest fixtures don't have that issue, as they're only run when you include the fixture for DI

I don't see how that prevents any of the basic problems raised in the article.

py.test avoids XUnit or unittest style class-based tests for this reason (though it will run them if you insist). It opts for simple test functions instead. Fixtures are passed in explicitly as parameters rather than implicitly as class members or whatnot. The result of all this is quite similar to what the author proposes.

Pytest with Mixer [1] really lowers the barrier to entry.

[1] https://mixer.readthedocs.io

Nice. How does it compare to factory boy ?

Sorry for the late reply, I reckon I've more than halved the amount of set up code I have to write by switching to Mixer.

Also pytest have pytest-bdd[1] for BDD, with that in mind you can use pytest for unit tests and behave tests, with only one runner is just awesome (because you write your fixtures only once)

Also good to mention pytest-xdist[2] for distributed testing...

[1]: https://pypi.python.org/pypi/pytest-bdd

[2]: https://docs.pytest.org/en/3.0.0/xdist.html

Just an FYI, normal fixtures can use 'yield', there is no need to use 'yield_fixture' anymore

Hah, good to know. Maybe I haven't bumped pytest in a while.

My favorite feature of pytest is pytest.mark.parametrize, which makes it easy to do table driven testing.

what is "table driven testing"?

I've never heard of that term being used but parametrize helps in situations where:

a) You have a slew of test inputs that all need to be tested through the same function, but you don't want to duplicate code.

b) You want something like "test with every combination of [x,y,z] for parameter a and [j,k,l] for parameter b". This is probably what the grandparent is referring to.

c)You have an even more complicated scheme, which you can define.

This is better than just having a for loop over a pre-generated list of parameters and calling a function with the same assertions, because pytest sees and handles them as separate but related test cases (e.g. when reporting errors, crash handling, fixtures, etc)

Yes. But what's striking me is that one woud ever want to test only one input state. If I have to test function f(x) and see if its output is as expected, I always want to test many inputs (including "silly" ones like wrong type, nulls, extremes). Writing one test for each of them is absurd, just give a list of inputs, a list of expected outputs and check them all.

pytest all day