4 ms·

pytest: https://docs.pytest.org/en/latest/ https://docs.pytest.org/en/latest/ The dependency injection for fixtures is somewhat of a magical entity, but overa

pytest: https://docs.pytest.org/en/latest/ https://docs.pytest.org/en/latest/ The dependency injection for fixtures is somewhat of a magical entity, but overall I've found it's the most efficient way to hammer out good tests on the standard unit/integration test spectrum. The default mode of operation doesn't even require importing pytest: Just write files named ending with `_test.py`, functions starting with `test`, and bare bones assertions. `yield_fixture` works well with the typical mock-and-assert-on python test pattern. Plenty of plugins out there for more exotic features, like asyncio, parallelization (though test parallelization tends to be much more problematic beyond "run tests at the same time"), output to <format>, etc too.

orf 9y ago
Just an FYI, normal fixtures can use 'yield', there is no need to use 'yield_fixture' anymore
- bpicolo 9y ago
  Hah, good to know. Maybe I haven't bumped pytest in a while.
sametmax 9y ago
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.
- allover 9y ago
  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 https://robots.thoughtbot.com/lets-not
  - bpicolo 9y ago
    pytest fixtures don't have that issue, as they're only run when you include the fixture for DI
    - allover 9y ago
      > 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.
      - makmanalp 9y ago
        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.
- drcongo 9y ago
  Pytest with Mixer [1] really lowers the barrier to entry. [1] https://mixer.readthedocs.io https://mixer.readthedocs.io
  - sametmax 9y ago
    Nice. How does it compare to factory boy ?
    - drcongo 9y ago
      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.
gbog 9y ago
My favorite feature of pytest is pytest.mark.parametrize, which makes it easy to do table driven testing.
- amirouche 9y ago
  what is "table driven testing"?
  - makmanalp 9y ago
    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)
    - gbog 9y ago
      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.
naspeh 9y ago
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 https://pypi.python.org/pypi/pytest-bdd [2]: https://docs.pytest.org/en/3.0.0/xdist.html https://docs.pytest.org/en/3.0.0/xdist.html
makmanalp 9y ago
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 https://www.youtube.com/watch?v=jmsk1QZQEvQ
mylons 9y ago
pytest all day

orf 9y ago

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

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

sametmax 9y ago

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.

allover 9y ago
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 https://robots.thoughtbot.com/lets-not
- bpicolo 9y ago
  pytest fixtures don't have that issue, as they're only run when you include the fixture for DI
  - allover 9y ago
    > 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.
    - makmanalp 9y ago
      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.
drcongo 9y ago
Pytest with Mixer [1] really lowers the barrier to entry. [1] https://mixer.readthedocs.io https://mixer.readthedocs.io
- sametmax 9y ago
  Nice. How does it compare to factory boy ?
  - drcongo 9y ago
    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.

gbog 9y ago

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

amirouche 9y ago
what is "table driven testing"?
- makmanalp 9y ago
  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)
  - gbog 9y ago
    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.

naspeh 9y ago

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 https://pypi.python.org/pypi/pytest-bdd [2]: https://docs.pytest.org/en/3.0.0/xdist.html https://docs.pytest.org/en/3.0.0/xdist.html

makmanalp 9y ago

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 https://www.youtube.com/watch?v=jmsk1QZQEvQ

mylons 9y ago

pytest all day