Features

Writing tests is easier

nose collects tests from unittest.TestCase subclasses, of course. But you can also write simple test functions, and test classes that are not subclasses of unittest.TestCase. nose also supplies a number of helpful functions for writing timed tests, testing for exceptions, and other common use cases. See Writing tests and Testing tools for more.

Running tests is easier

nose collects tests automatically, as long as you follow some simple guidelines for organizing your library and test code. There's no need to manually collect test cases into test suites. Running tests is responsive, since nose begins running tests as soon as the first test module is loaded. See Finding and running tests for more.

Setting up your test environment is easier

nose supports fixtures at the package, module, class, and test case level, so expensive initialization can be done as infrequently as possible. See Fixtures for more.

Doing what you want to do is easier

nose has plugin hooks for loading, running, watching and reporting on tests and test runs. If you don't like the default collection scheme, or it doesn't suit the layout of your project, or you need reports in a format different from the unittest standard, or you need to collect some additional information about tests (like code coverage or profiling data), you can write a plugin to do so. See Writing pluginsfor more. nose comes with a number of builtin plugins, for instance:

• Output capture

Unless called with the -s (--nocapture) switch, nose will capture stdout during each test run, and print the captured output only for tests that fail or have errors. The captured output is printed immediately following the error or failure output for the test. (Note that output in teardown methods is captured, but can't be output with failing tests, because teardown has not yet run at the time of the failure.)

• Assert introspection

When run with the -d (--detailed-errors) switch, nose will try to output additional information about the assert expression that failed with each failing test. Currently, this means that names in the assert expression will be expanded into any values found for them in the locals or globals in the frame in which the expression executed.

In other words if you have a test like:

def test_integers():
    a = 2
    assert a == 4, "assert 2 is 4"

You will get output like:

File "/path/to/file.py", line XX, in test_integers:
      assert a == 4, "assert 2 is 4"
AssertionError: assert 2 is 4
  >>  assert 2 == 4, "assert 2 is 4"

Please note that dotted names are not expanded, and callables are not called in the expansion.

Setuptools integration

nose may be used with the setuptools test command. Simply specify nose.collector as the test suite in your setup file:

setup (
    # ...
    test_suite = 'nose.collector'
)

Then to find and run tests, you can run:

python setup.py test

When running under setuptools, you can configure nose settings via the environment variables detailed in the nosetests script usage message, or the setup.cfg or ~/.noserc or ~/.nose.cfg config files.

Please note that when run under the setuptools test command, some plugins will not be available, including the builtin coverage, and profiler plugins.

nose also includes its own setuptools command, nosetests, that provides support for all plugins and command line options. See [#commands nose.commands] for more information about the nosetests command.

Do not edit above this line. Content above this line is automatically generated and edits above this line will be discarded.

Comments