Hacker News Reader

Comment by giancarlostoro | Hacker News Reader

I'm fairly new to Python and wondering of any reasons to use these as opposed to the standard unittest package that comes with Python?

View on HN

It has an excellent runner and makes much better use of Python features:

* you can define tests as free functions (you don't have to, it also supports classes and even regular unittest cases, you can use pytest to run your existing suite)

* exceptions aside it uses the standard `assert` statement

* fixtures are DI'd, independent from tests and much more flexible than the setUp/tearDown dance

* tests are configured and fixtures are defined using decorators & generators

* excellent support for data-driven tests (parametrized tests and fixtures)

* there is a wealth of reusable third-party plugins[0] ranging from framework helpers[1] to test parallelisation and distribution[2]

[0] http://plugincompat.herokuapp.com

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

[2] https://pypi.python.org/pypi/pytest-xdist

> fixtures are DI'd, independent from tests and much more flexible than the setUp/tearDown dance

If this were the only difference, it'd still be enough. Inevitably I end up with a unittest.TestCase with 30 tests, all of which mock out some resource. Except for 1. That one wants to mock out a different resource while leaving the first intact.

* With unittest: either split that test out into its own TestCase (duplicating most of the original, except for the part I don't want, or coming up with an inheritance tree with is always ugly with unittest), or

* Remove all the unwanted mocks inside that test.

* With pytest: don't pass the mocking fixture into that test.

Yup. The ability to compose fixtures too, a test can depend on a fixture but so can an other fixture.

Combined with flexible scopes and the ability to mark and select/deselect tests based on name and marks it makes for genuinely great stuff e.g. some of your tests depend on the database, you can have a session-scoped fixture handling a connection, then a function-scoped one depending on it and getting a cursor, and if you don't select any test depending on the latter no connection will be created at any point.

If for no other reason, pytest requires a lot less boilerplate.

Pytest fixtures are also quite a bit more flexible than unittest's setUp and tearDown methods, although they take a little while to really understand (at least they did for me) since they use some magic.

Yield fixtures are just awesome for mocking, but the magical global dependency injection definitely makes you feel a bit weird on occasion

especially in combination with pytest-mock.

I find pytest a lot easier to work with, in general, particularly with their approach to fixtures https://docs.pytest.org/en/latest/fixture.html . I find I'm writing way less boilerplate and a lot cleaner and neater tests. Also I absolutely love parametrize: https://docs.pytest.org/en/latest/parametrize.html

Pytest is more pythonic than the xUnitTest suite in the standard library. It is authored by the same genius who authored pypy, hence the wow about it. Nosetest was forked off pytest as a way to maintain the project several years ago, but pytest came back to life and eventually superseded nose. The fixtures in pytest is a very clever way to structure your tests around dynamic "given" set of inputs.

Parametrized tests are quite powerful and you can be creative with them. For example, I am using them in integration testing (for this test, I need process A and process B as well as a string from set C): https://vincent.bernat.im/en/blog/2016-testing-pytest-linux-...

You can define the lifetime of each parameter (just the test, the class or the whole testing session). This makes it very flexible.

The use of "assert" is magic in the sense that in case of failure, you get helpful values. "assert a == b" will show you the values of "a" and "b" in case of failure.

'pytest --lf' reruns only tests that have failed during the previous run. Helps a lot when your test suite is not very fast.

Reply on news.ycombinator.com