tl;dr: rant about pytest, from the point of view of a packager who had to debug dozens of packages using pytest across multiple platforms.

In the python world, the two most common packages used for testing in addition to unittest(2) are nose and py.test. Both provide two fundamental functionalities: running test (aka they provide a test runner), and a testing framework to write tests. Some of the features provided by the framework are parameterized tests, writing function as tests, etc... I try to avoid both libraries in general, especially as testing frameworks, and since I have had this discussion a few too many times at work and outside, I thought I would write a few words explaining why I find those libraries problematic.

My first issue is related to test discovery: to make discovery "simple" to use, both nose and py.test have fairly complex logic to detect tests. For example, it is fairly common to write tests inside the python package (e.g. foo/tests for package foo), but instead of simply mandating foo.tests to be a proper package, nose and py.test will automatically look for python files even within non packages. They also allow to write tests without having to subclass from unittest.TestCase. To provide this feature, they rely on complicated, and in my experience brittle logic to find tests. You may object that it should be possible to write tests as simple functions instead of subclasses, but a decorator to label the test functions would be much simpler (and arguably more idiomatic python). This point goes beyond mere aesthetic: by making test discovery implementation simple, it is harder to miss tests by accident, and easier to manipulate them programmatically. For example, a feature I've missed for a long time is the ability to execute tests from its name (be it a method, class or file). It is hard to do well if finding your tests is complicated. Enforcing tests to be within proper python packages also makes testing installed packages easier.

Another feature of pytest is the ability to write test assertions through python's assert statement. Besides being an abuse of assert intent, this is often problematic because py.test needs to figure out the appropriate unittest.assertMethod to use (often guessing wrong and causing unreadable test failures). It makes writing test slightly easier, at the cost of harder debugging.

Parameterized tests is another annoyance. Both nose and py.test offer parameterized tests, so that you can run the same method with different arguments, run as different tests. This is certainly useful as a feature, but IMO both nose and py.test make that feature not that useful in practice: it is difficult to identify which test fails, and to my knowledge impossible to run a subset of the parameterized test.

Overall, those testing frameworks are fairly inflexible for non developers, and debugging test issues in packages using py.test especially problematic. In most cases, straight up unittest(2) would be enough, except for parameterized tests, where a proper upstream method in unittest is still waiting to happen. If you can live with its missing features, I personally recommend haas from my friend Simon Jagoe. One feature I especially like is the ability to run tests based on their name.