Abandon nosetests.

Sadly, nosetests appears to be abandonware according to their documentation:

Nose has been in maintenance mode for the past several years and will likely cease without a new person/team to take over maintainership.

Given that we will now need to migrate our testing infrastructure away from nose, we should consider where we need to move. My suggestion would be to move to py.test: writing tests for py.test is generally a nicer experience than writing traditional unittest style tests, and it has fewer requirements to do weird unittest importing. However, I’m happy to get feedback from the other contributors about what they’d like to do.

The work required to complete this would be as follows:

• Initial PR to move from nosetests as the test runner to the new runner, with only the changes to the testing we actually need to get those tests to run.
• Subsequent PRs to incrementally migrate our test suite to the style of the new runner, instead of unittest style, if applicable.

Thoughts?

[sigmavirus24]

I’ll add less objective items as well:

Writing py.test tests are a joy because:

• You can still use unittest if you want

• You don’t need to remember which assertFoo methods actually exist on your version of Python and which don’t (for that, you need unittest2)

• You don’t need to go through inheritance hell to figure out what is setting up self.frob on your class that you’re using when it turns out to be wrong

• You don’t need to know about the difference between addCleanup and tearDown and which is better or worse for whatever subtle reasons

As for a few other non-requirements:

• We don’t need to emit our tests results as subunit

• Py.test works well with pretend, mock, and any other stubbing or mocking tool we’d like

• Py.test test discovery works well on all versions of Python we support. To get that support we’d have to (again) rely on unittest2, testrepository, or some other item.

• Py.test has a wealth of plugins that make life so much nicer meaning we have to do less to write tests

[Lukasa]

My experience has been that py.test has a number of major advantages. Most notable, though, is that because it is not in the standard library it does not have a feature set that varies based on Python version. I count the presence of unittest in the standard library as a downside, not an upside, because it leads to either conditional code, conditional imports, or being unable to use useful features that are only present in newer releases.

As to what is in py.test that is not in unittest:

1. Parametrized tests, which allow us to write a large number of tests very swiftly and without code duplication that appear as separate tests in the result output.
2. Reduction of boilerplate. The less you have to type to write a test, the more likely you are to write a test, and indeed to write more tests.
3. Fixtures allow clean dependency injection without resorting to metaclasses.
4. Most importantly, removes the JUnit coding style, which is extremely un-pythonic.