History

Johannes Erdfelt a97bde442f Clear created attributes when tearing down tests unittest will keep each test case around after completion pinning any objects references by attributes on the test case. This can bloat the memory used during a full test suite run to the point where the test suite will require much more memory than running all of the services does. On systems witout lots of memory, test suite failures will occur as test cases cannot fork to execute programs. Clearing out __dict__ of any attributes that don't start with a _ (since some are needed by unittest itself) reduces memory significantly. This does require the super class tearDown to be called last in some cases however. Change-Id: I0e660b6c2a77c5613c5a523ba0a64c3d7f6dd128	2012-03-07 15:52:40 +00:00
..
README.rst	Clear created attributes when tearing down tests	2012-03-07 15:52:40 +00:00

Johannes Erdfelt a97bde442f Clear created attributes when tearing down tests

unittest will keep each test case around after completion pinning any
objects references by attributes on the test case. This can bloat
the memory used during a full test suite run to the point where
the test suite will require much more memory than running all of
the services does. On systems witout lots of memory, test suite
failures will occur as test cases cannot fork to execute programs.

Clearing out __dict__ of any attributes that don't start with a _
(since some are needed by unittest itself) reduces memory
significantly. This does require the super class tearDown to be
called last in some cases however.

Change-Id: I0e660b6c2a77c5613c5a523ba0a64c3d7f6dd128

2012-03-07 15:52:40 +00:00

README.rst

Clear created attributes when tearing down tests

2012-03-07 15:52:40 +00:00

README.rst

OpenStack Nova Testing Infrastructure

A note of clarification is in order, to help those who are new to testing in OpenStack nova:

actual unit tests are created in the "tests" directory;
the "testing" directory is used to house the infrastructure needed to support testing in OpenStack Nova.

This README file attempts to provide current and prospective contributors with everything they need to know in order to start creating unit tests and utilizing the convenience code provided in nova.testing.

Note: the content for the rest of this file will be added as the work items in the following blueprint are completed: https://blueprints.launchpad.net/nova/+spec/consolidate-testing-infrastructure

Test Types: Unit vs. Functional vs. Integration

TBD

Writing Unit Tests

TBD

Using Fakes

TBD

test.TestCase

The TestCase class from nova.test (generally imported as test) will automatically manage self.stubs using the stubout module and self.mox using the mox module during the setUp step. They will automatically verify and clean up during the tearDown step.

If using test.TestCase, calling the super class setUp is required and calling the super class tearDown is required to be last if tearDown is overriden.

Writing Functional Tests

TBD

Writing Integration Tests

TBD

Tests and assertRaises

When asserting that a test should raise an exception, test against the most specific exception possible. An overly broad exception type (like Exception) can mask errors in the unit test itself.

Example:

self.assertRaises(exception.InstanceNotFound, db.instance_get_by_uuid,
                  elevated, instance_uuid)