1. Jason Pellerin
  2. nose-pycon


nose-pycon / README.txt

0.10 dev branch -- unstable


This branch is highly unstable and under active development. Unless
you are working on nose itself, you should not be using this branch!

What's going on here?

0.10 will be a major release of nose, with deep changes to test
loading and running that aim to make nose's parts (the TestLoader,
etc) more plug-in compatible with unittest, as well as simpler to
understand and hack. Other goals include:

* Making use of commandline arguments more intuitive. Currently you
  *can't* say `nosetests foo.py` to make nose load tests from foo.py
  -- nose doesn't think its a test file. You know better, but nose
  won't listen. This is dumb.

* Making sure fixtures (setup/teardown) are only ever executed when
  there are tests underneath them.

* Providing more hooks for plugins to control loading of tests,
  imports, and fixture state.

* Providing a single interface around all test types, to help plugins
  interact with tests more easily.

This involves some major changes to how nose loads and runs tests.
Changes to loading

Currently, nose's TestLoader has many methods with the same names as
unittests's TestLoader, but those methods take different arguments and
in general can't be plugged in where unittest's methods work now. The
major reason for this was the design decision that nose should be
discovery-first, that is, it should never operate on a test it didn't

Changes to fixtures

Currently, module and package level fixtures are executed by test
suite subclasses, in those suite's setUp and tearDown methods. This
produces a number of undesireable side effects, including that
fixtures execute even when no tests are collected, and that it's
impossible to simple walk the discovery tree and collect all tests
before (or instead of) running them.

nose 0.10 will fix this by separating the fixture context from the
loader, using a new class (nose.fixture.Context) to manage the
fixtures that surround any group of tests. One fixture context will be
used per loader instance, and each test will be wrapped in a
contexualized test case instance that references the context. The
context tracks which tests belong to what modules, and it runs the
module-level setUp before the first test from any module and the
module-level tearDown after the last test from any module (if the
module-level setUp succeeded). This works only because loading and
discovery are now depth-first within modules, so all tests from a
module (including packages and subpackages) are loaded before the
first is executed.

More details to come (watch this space)