nose vs pytest – what are the (subjective) differences that should make me pick either?
Question:
I’ve started working on a rather big (multithreaded) Python project, with loads of (unit)tests. The most important problem there is that running the application requires a preset environment, which is implemented by a context manager. So far we made use of a patched version of the unit test runner that would run the tests inside this manager, but that doesn’t allow switching context between different test modules.
Both nose and pytest do support such a thing because they support fixtures at many granularities, so we’re looking into switching to nose or pytest. Both these libraries would also support ‘tagging’ tests and run only these tagged subsets, which is something we also would like to do.
I have been looking through the documentation of both nose and pytest a bit, and as far as I can see the bigger part of those libraries essentially support the same functionality, except that it may be named differently, or require slightly different syntax. Also, I noted some small differences in the available plugins (nose has multiprocess-support, pytest doesn’t seem to for instance)
So it seems, the devil is in the detail, which means (often at least) in personal taste and we better go with the library that fits our personal taste best.
So I’d to ask for a subjective argumentation why I should be going with nose or pytest in order to choose the library/community combo that best fits our needs.
Answers:
I used to use Nose because it was the default with Pylons. I didn’t like it at all. It had configuration tendrils in multiple places, virtually everything seemed to be done with an underdocumented plugin which made it all even more indirect and confusing, and because it did unittest tests by default, it regularly broke with Unicode tracebacks, hiding the sources of errors.
I’ve been pretty happy with py.test the last couple years. Being able to just write a test with assert out of the box makes me hate writing tests way less, and hacking whatever I need atop the core has been pretty easy. Rather than a fixed plugin interface it just has piles of hooks, and pretty understandable source code should you need to dig further. I even wrote an adapter for running Testify tests under py.test, and had more trouble with Testify than with py.test.
That said, I hear nose has plugins for classless tests and assert introspection nowadays, so you’ll probably do fine with either. I still feel like I can hit the ground running with py.test, though, and I can understand what’s going on when it breaks.
I’ve started working on a rather big (multithreaded) Python project, with loads of (unit)tests. The most important problem there is that running the application requires a preset environment, which is implemented by a context manager. So far we made use of a patched version of the unit test runner that would run the tests inside this manager, but that doesn’t allow switching context between different test modules.
Both nose and pytest do support such a thing because they support fixtures at many granularities, so we’re looking into switching to nose or pytest. Both these libraries would also support ‘tagging’ tests and run only these tagged subsets, which is something we also would like to do.
I have been looking through the documentation of both nose and pytest a bit, and as far as I can see the bigger part of those libraries essentially support the same functionality, except that it may be named differently, or require slightly different syntax. Also, I noted some small differences in the available plugins (nose has multiprocess-support, pytest doesn’t seem to for instance)
So it seems, the devil is in the detail, which means (often at least) in personal taste and we better go with the library that fits our personal taste best.
So I’d to ask for a subjective argumentation why I should be going with nose or pytest in order to choose the library/community combo that best fits our needs.
I used to use Nose because it was the default with Pylons. I didn’t like it at all. It had configuration tendrils in multiple places, virtually everything seemed to be done with an underdocumented plugin which made it all even more indirect and confusing, and because it did unittest tests by default, it regularly broke with Unicode tracebacks, hiding the sources of errors.
I’ve been pretty happy with py.test the last couple years. Being able to just write a test with assert out of the box makes me hate writing tests way less, and hacking whatever I need atop the core has been pretty easy. Rather than a fixed plugin interface it just has piles of hooks, and pretty understandable source code should you need to dig further. I even wrote an adapter for running Testify tests under py.test, and had more trouble with Testify than with py.test.
That said, I hear nose has plugins for classless tests and assert introspection nowadays, so you’ll probably do fine with either. I still feel like I can hit the ground running with py.test, though, and I can understand what’s going on when it breaks.