integrate 1.0.0

TestCase class

The TestCase class is the workhorse of the integrate framework. It has some functions you may override in a subclass in addition to adding test functions:

• def setup_all(self): This function is run at the beginning of the test case class before any test is started

• def teardown_all(self): This function is run at the end of the test case class after all tests have finished

• def setup_test(self): This function is run before each test in the test case

• def teardown_test(self): This function is run after each test in the test case

You can run the test case class by it’s own by calling YourTestCase().run() or rely on the test runner

There are some interesting initialization parameters:

• verbosity, how verbose the test output should be (min: 0, max: 2, default: 2)

• checker, which Check subclass to use, usually you will use the default Check class, but you may extend that to add methods to the check object all tests receive

@test decorator

All functions that should be picked up by the TestCase class have to be decorated with @test() (notice the parentheses!), the decorator has some optional parameters:

• skip boolean, defaults to False, set to True to skip a test

• skip_if_failed list of strings, names of test functions that have to succeed (not fail or be skipped) in order for this function to run, defaults to an empty list

• depends list of strings, names of test functions that should be run before this function, defaults to an empty list

The test functions have 2 parameters: self and check, for the description of check read on.

Check class

All errors that surface in a test should be found and logged by an instance of the Check class. You may subclass this class to add additional checker functions and insert it into the TestCase or TestRunner initializer.

The assertion API looks like the following, if there is a message parameter it usually is optional and may be left out. User messages are prepended to an error message:

• equal(a, b, message=None) Check if two values are equal

• not_equal(a, b, message=None) Check if two values are not equal

• is_none(a, message=None) Check if a value is None

• is_not_none(a, message=None) Check if a value is not None

• is_true(a, message=None) Check if a value is True

• is_false(a, message=None) Check if a value is False

• fail(message) Just log an error message

• raises(exception_type, function, *args, **kwargs) Check if a function raises a specified exception type, args and kwargs are forwarded to the function

• does_not_raise(function, *args, **kwargs) Check if a function does not raise an exception, args and kwargs are forwarded to the function

All check functions should return True if the check succeeded and False if it failed if they don’t have to return any other result (like the raises and does_not_raise functions which return the result of the function or None)

Exceptions in test functions will still cancel the test function and log the exception to the error log if you don’t wrap it with a raises() call. The traceback of an exception caught by the toplevel will be not of much use though if you can’t pinpoint the location based on the exception type. If you just want to catch all exceptions use check.raises(Exception, myFunc, "myParam")

For extending the Check class there is a, rather small, extension API:

• log_error(error, message, detail=None, strip=4) Use this function to add an error to the list, a corresponding stack trace is appended automatically. The error parameter is a textual one line description of the error, the message parameter is a user message. Use the detail parameter to give a detailed error description if needed. Only modify the strip parameter if your stacktrace gets entries after the error location in the test, by default it strips the last 4 stack frames as these are in the testing framework and just clobber the stack traces.

• error_message() Use this for debugging, this function joins all error messages into one string

TestRunner class

The TestRunner class is the entry point for automatically discovering tests in a project and running them. It has some initialization parameters:

• verbosity verbosity of test output (min: 0, max: 2, default: 2)

• dirs list of directories to scan for tests, defaults to current directory. Directories are scanned recursively.

• pattern file name pattern to search (argument to fnmatch) defaults to the python best practice *_test.py

• checker the Check subclass to send to the tests, if you have subclassed the Check class put your class here, defaults to the unmodified Check class

To start the tests instanciate the test runner and call the run() function:

from integrate import TestRunner
TestRunner().run()

If you want to run just some tests of your test suite you may either run the tests directly by calling run() on the TestCase subclass or by supplying a filter to the run() function of the test runner like so:

TestRunner().run(only='special.')

This example would only run tests which have a module name that starts with special. the module names are generated by replacing all slashes of the python file path with a dot and removing the .py extension.

A test file that is stored in the path special/tests/runme.py will get a module name of special.tests.runme.

If you only want to look at what the Test runner would actually do use the plan() function, this just displays a list of test that would be executed and the order of execution instead of really running the tests. It has the same parameters as the run() function.