fixtures 4.1.0

Errors in setUp

The examples above used _setUp rather than setUp because the base class implementation of setUp acts to reduce the chance of leaking external resources if an error is raised from _setUp. Specifically, setUp contains a try/except block which catches all exceptions, captures any registered detail objects, and calls self.cleanUp before propagating the error. As long as you take care to register any cleanups before calling the code that may fail, this will cause them to be cleaned up. The captured detail objects are provided to the args of the raised exception.

If the error that occurred was a subclass of Exception then setUp will raise MultipleExceptions with the last element being a SetupError that contains the detail objects. Otherwise, to prevent causing normally uncatchable errors like KeyboardInterrupt being caught inappropriately in the calling layer, the original exception will be raised as-is and no diagnostic data other than that from the original exception will be available.

Shared Dependencies

A common use case within complex environments is having some fixtures shared by other ones.

Consider the case of testing using a TempDir with two fixtures built on top of it; say a small database and a web server. Writing either one is nearly trivial. However handling reset() correctly is hard: both the database and web server would reasonably expect to be able to discard operating system resources they may have open within the temporary directory before its removed. A recursive reset() implementation would work for one, but not both. Calling reset() on the TempDir instance between each test is probably desirable but we don’t want to have to do a complete cleanUp of the higher layer fixtures (which would make the TempDir be unused and trivially resettable. We have a few options available to us.

Imagine that the webserver does not depend on the DB fixture in any way - we just want the webserver and DB fixture to coexist in the same tempdir.

A simple option is to just provide an explicit dependency fixture for the higher layer fixtures to use. This pushes complexity out of the core and onto users of fixtures:

>>> class WithDep(fixtures.Fixture):
...     def __init__(self, tempdir, dependency_fixture):
...         super(WithDep, self).__init__()
...         self.tempdir = tempdir
...         self.dependency_fixture = dependency_fixture
...     def setUp(self):
...         super(WithDep, self).setUp()
...         self.addCleanup(self.dependency_fixture.cleanUp)
...         self.dependency_fixture.setUp()
...         # we assume that at this point self.tempdir is usable.
>>> DB = WithDep
>>> WebServer = WithDep
>>> tempdir = fixtures.TempDir()
>>> db = DB(tempdir, tempdir)
>>> server = WebServer(tempdir, db)
>>> server.setUp()
>>> server.cleanUp()

Another option is to write the fixtures to gracefully handle a dependency being reset underneath them. This is insufficient if the fixtures would block the dependency resetting (for instance by holding file locks open in a tempdir - on Windows this will prevent the directory being deleted).

Another approach which fixtures neither helps nor hinders is to raise a signal of some sort for each user of a fixture before it is reset. In the example here, TempDir might offer a subscribers attribute that both the DB and web server would be registered in. Calling reset or cleanUp on the tempdir would trigger a callback to all the subscribers; the DB and web server reset methods would look something like:

>>> def reset(self):
...     if not self._cleaned:
...         self._clean()

(Their action on the callback from the tempdir would be to do whatever work was needed and set self._cleaned.) This approach has the (perhaps) surprising effect that resetting the webserver may reset the DB - if the webserver were to be depending on tempdir.reset as a way to reset the webserver’s state.

Another approach which is not currently implemented is to provide an object graph of dependencies and a reset mechanism that can traverse that, along with a separation between ‘reset starting’ and ‘reset finishing’ - the DB and webserver would both have their reset_starting methods called, then the tempdir would be reset, and finally the DB and webserver would have reset_finishing called.

ByteStream

Trivial adapter to make a BytesIO (though it may in future auto-spill to disk for large content) and expose that as a detail object, for automatic inclusion in test failure descriptions. Very useful in combination with MonkeyPatch:

>>> fixture = fixtures.StringStream('my-content')
>>> fixture.setUp()
>>> with fixtures.MonkeyPatch('sys.something', fixture.stream):
...     pass
>>> fixture.cleanUp()

This requires the fixtures[streams] extra.

EnvironmentVariable

Isolate your code from environmental variables, delete them or set them to a new value:

>>> fixture = fixtures.EnvironmentVariable('HOME')

FakeLogger

Isolate your code from an external logging configuration - so that your test gets the output from logged messages, but they don’t go to e.g. the console:

>>> fixture = fixtures.FakeLogger()

FakePopen

Pretend to run an external command rather than needing it to be present to run tests:

>>> from io import BytesIO
>>> fixture = fixtures.FakePopen(lambda _:{'stdout': BytesIO('foobar')})

LogHandler

Replace or extend a logger’s handlers. The behavior of this fixture depends on the value of the nuke_handlers parameter: if true, the logger’s existing handlers are removed and replaced by the provided handler, while if false the logger’s set of handlers is extended by the provided handler:

>>> from logging import StreamHandler
>>> fixture = fixtures.LogHandler(StreamHandler())

MockPatchObject

Adapts mock.patch.object to be used as a fixture:

>>> class Fred:
...     value = 1
>>> fixture = fixtures.MockPatchObject(Fred, 'value', 2)
>>> with fixture:
...     Fred().value
2
>>> Fred().value
1

MockPatch

Adapts mock.patch to be used as a fixture:

>>> fixture = fixtures.MockPatch('subprocess.Popen.returncode', 3)

MockPatchMultiple

Adapts mock.patch.multiple to be used as a fixture:

>>> fixture = fixtures.MockPatchMultiple('subprocess.Popen', returncode=3)

MonkeyPatch

Control the value of a named Python attribute:

>>> def fake_open(path, mode):
...     pass
>>> fixture = fixtures.MonkeyPatch('__builtin__.open', fake_open)

Note that there are some complexities when patching methods - please see the API documentation for details.

NestedTempfile

Change the default directory that the tempfile module places temporary files and directories in. This can be useful for containing the noise created by code which doesn’t clean up its temporary files. This does not affect temporary file creation where an explicit containing directory was provided:

>>> fixture = fixtures.NestedTempfile()

PackagePathEntry

Adds a single directory to the path for an existing Python package. This adds to the package.__path__ list. If the directory is already in the path, nothing happens, if it isn’t then it is added on setUp and removed on cleanUp:

>>> fixture = fixtures.PackagePathEntry('package/name', '/foo/bar')

PythonPackage

Creates a python package directory. Particularly useful for testing code that dynamically loads packages/modules, or for mocking out the command line entry points to Python programs:

>>> fixture = fixtures.PythonPackage('foo.bar', [('quux.py', '')])

PythonPathEntry

Adds a single directory to sys.path. If the directory is already in the path, nothing happens, if it isn’t then it is added on setUp and removed on cleanUp:

>>> fixture = fixtures.PythonPathEntry('/foo/bar')

Stream

Trivial adapter to expose a file-like object as a detail object, for automatic inclusion in test failure descriptions. StringStream and BytesStream provided concrete users of this fixture.

This requires the fixtures[streams] extra.

StringStream

Trivial adapter to make a StringIO (though it may in future auto-spill to disk for large content) and expose that as a detail object, for automatic inclusion in test failure descriptions. Very useful in combination with MonkeyPatch:

>>> fixture = fixtures.StringStream('stdout')
>>> fixture.setUp()
>>> with fixtures.MonkeyPatch('sys.stdout', fixture.stream):
...     pass
>>> fixture.cleanUp()

This requires the fixtures[streams] extra.

TempDir

Create a temporary directory and clean it up later:

>>> fixture = fixtures.TempDir()

The created directory is stored in the path attribute of the fixture after setUp.

TempHomeDir

Create a temporary directory and set it as $HOME in the environment:

>>> fixture = fixtures.TempHomeDir()

The created directory is stored in the path attribute of the fixture after setUp.

The environment will now have $HOME set to the same path, and the value will be returned to its previous value after tearDown.

Timeout

Aborts if the covered code takes more than a specified number of whole wall-clock seconds.

There are two possibilities, controlled by the gentle argument: when gentle, an exception will be raised and the test (or other covered code) will fail. When not gentle, the entire process will be terminated, which is less clean, but more likely to break hangs where no Python code is running.

WarningsCapture

Capture warnings for later analysis:

>>> fixture = fixtures.WarningsCapture()

The captured warnings are stored in the captures attribute of the fixture after setUp.

WarningsFilter

Configure warnings filters during test runs:

>>> fixture = fixtures.WarningsFilter(
...     [
...         {
...             'action': 'ignore',
...             'message': 'foo',
...             'category': DeprecationWarning,
...         },
...     ]
... )

Order is important: entries closer to the front of the list override entries later in the list, if both match a particular warning.