88

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.

Vikrant
  • 4,920
  • 17
  • 48
  • 72
Jakob van Bethlehem
  • 1,066
  • 1
  • 7
  • 10
  • Just noted that more or less the same question was asked also [here](http://stackoverflow.com/questions/191673/preferred-python-unit-testing-framework) - but that's five years ago, so I still think reasking the question makes sense – Jakob van Bethlehem Apr 04 '14 at 08:04
  • 9
    `pytest` does support multiprocess support through the [pytest-xdist](https://bitbucket.org/hpk42/pytest-xdist) plugin. – Bruno Oliveira Apr 04 '14 at 10:46
  • 2
    As an aside, context managers are just plain Python objects, and you could call `manager.__enter__()` in your `TestCase.setUp()`, and `manager.__exit__()` in your `tearDown()`. – rescdsk Dec 21 '14 at 22:29
  • 4
    Nose is [no longer being maintained](https://nose.readthedocs.io/en/latest/#note-to-users). – toasted_flakes Sep 05 '16 at 12:37

1 Answers1

91

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.

Eevee
  • 47,412
  • 11
  • 95
  • 127
  • 2
    Some problems with hidding tracebacks were fixed around about nose 0.11, many years ago now. Since the Python 3 port I expect any unicode tracebacks are less frequent (though personally I think I only ran into a unicode problem with nose once, which cropped up when combining it with some test case base class that did some "trick" that didn't really make sense -- so that turned out to be not nose's fault). I suspect in truth both tools have had the rough edges knocked off them over the years, so perhaps you will like like best whichever you used most recently ;-) – Croad Langshan Jul 04 '15 at 11:46
  • what about the recent documentation part. i am also confused whether to use nosetests or py.test. both seem to be equally good but as I read, most of the people are using nosetests these days. What could be the reason when py.tests has better set of multiprocessing libraries available? – proprius Jan 02 '16 at 06:41
  • 1
    @proprius it might just be that nosetests came first. some frameworks added support for it, projects using those frameworks used it by default, and it spread. also, while py.test can run nose and unittest tests, its usual style isn't arranged around classes, so porting to py.test might feel daunting. – Eevee Jan 02 '16 at 08:02
  • 6
    i have started reading through the documentation part of pytest and I realized that for multiprocessing purpose as well as in terms of learning for a newbee, pytest is a better choice. – proprius Jan 02 '16 at 08:59