Torment¶

Collection of data and actions for a particular test case.

Intended as a base class for custom fixtures. Fixture provides an API that simplifies writing scalable test cases.

Creating Fixture objects is broken into two parts. This keeps the logic for a class of test cases separate from the data for particular cases while allowing re-use of the data provided by a fixture.

The first part of Fixture object creation is crafting a proper subclass that implements the necessary actions:

By default all actions are noops and simply do nothing but run is required. These actions allow complex class hierarchies to provide nuanced testing behavior. For example, Fixture provides the absolute bare minimum to test any Fixture and no more. By adding a set of subclasses, common initialization and checks can be performed at one layer while specific run decisions and checks can happen at a lower layer.

The second part of Fixture object creation is crafting the data. Tying data to a Fixture class should be done with torment.fixtures.register. It provides a declarative interface that binds a dictionary to a Fixture (keys of dictionary become Fixture properties). torment.fixtures.register creates a subclass that the rest of the torment knows how to transform into test cases that are compatible with nose.

Examples

Simplest Fixture subclass:

class MyFixture(Fixture):
    pass

Of course, to be useful the Fixture needs definitions of setup, run, and check that actually test the code we’re interested in checking:

def add(x, y):
    return x + y

class AddFixture(Fixture):
    def run(self):
        self.result = add(self.parameters['x'], self.parameters['y'])

    def check(self):
        self.context.assertEqual(self.result, self.expected)

This fixture uses a couple of conventions (not requirements):

1. self.parameters as a dictionary of parameter names to values
2. self.expected as the value we expect as a result
3. self.result as the holder inside the fixture between run and check

This show-cases the ridiculity of using this testing framework for simple functions that have few cases that require testing. This framework is designed to allow many cases to be easily and declaritively defined.

The last component required to get these fixtures to actually run is hooking them together with a context:

from torment import contexts

class AddUnitTest(contexts.TestContext, metaclass = contexts.MetaContext):
    fixture_classes = (
        MyFixture,
        AddFixture,
    )

The context that wraps a Fixture subclass should eventually inherit from TestContext (which inherits from unittest.TestCase and provides its assert methods). In order for nose to find and execute this TestContext, it must have a name that contains Test.

Properties

• category
• description (override)
• name (do not override)

Methods To Override

• __init__
• check
• initialize
• run (required)
• setup

Instance Variables

category¶

Fixture’s category (the containing testing module name)

Examples

Module:	test_torment.test_unit.test_fixtures.fixture_a44bc6dda6654b1395a8c2cbd55d964d
Category:	fixtures

check() → None[source]¶

Check that run ran as expected.

Note

Override as necessary. Default provided so re-defenition is not necessary.

Called after run and should be used to verify that run performed the expected actions.

description¶

Test name in nose output (intended to be overridden).

initialize() → None[source]¶

Post-data population initialization hook.

Note

Override as necessary. Default provided so re-defenition is not necessary.

Called during __init__ and after properties have been populated by torment.fixtures.register.

name¶

Method name in nose runtime.

setup() → None[source]¶

Pre-run initialization hook.

Note

Override as necessary. Default provided so re-defenition is not necessary.

Called after properties have been populated by torment.fixtures.register.