From b7714e82fdbede2dfe328eaae0add07f6e2b92c5 Mon Sep 17 00:00:00 2001 From: Monty Taylor Date: Mon, 11 Feb 2013 15:22:24 -0600 Subject: Update docs about testing. Add an entry to the HACKING file about testr. While in there, noticed a reference to the now-defunct nova/testing dir. Fixed that, moved the testing README into nova/tests and remove the nova/testing dir. Change-Id: Ibf6fb82658ba73eee9123fa53b340d0b72afb292 --- nova/testing/README.rst | 86 ------------------------------------------------ nova/testing/__init__.py | 0 nova/tests/README.rst | 78 +++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 78 insertions(+), 86 deletions(-) delete mode 100644 nova/testing/README.rst delete mode 100644 nova/testing/__init__.py create mode 100644 nova/tests/README.rst (limited to 'nova') diff --git a/nova/testing/README.rst b/nova/testing/README.rst deleted file mode 100644 index 4c341b7ed..000000000 --- a/nova/testing/README.rst +++ /dev/null @@ -1,86 +0,0 @@ -===================================== -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 Exceptions --------------------- -A properly written test asserts that particular behavior occurs. This can -be a success condition or a failure condition, including an exception. -When asserting that a particular exception is raised, the most specific -exception possible should be used. - -In particular, testing for Exception being raised is almost always a -mistake since it will match (almost) every exception, even those -unrelated to the exception intended to be tested. - -This applies to catching exceptions manually with a try/except block, -or using assertRaises(). - -Example:: - - self.assertRaises(exception.InstanceNotFound, db.instance_get_by_uuid, - elevated, instance_uuid) - -If a stubbed function/method needs a generic exception for testing -purposes, test.TestingException is available. - -Example:: - - def stubbed_method(self): - raise test.TestingException() - self.stubs.Set(cls, 'inner_method', stubbed_method) - - obj = cls() - self.assertRaises(test.TestingException, obj.outer_method) diff --git a/nova/testing/__init__.py b/nova/testing/__init__.py deleted file mode 100644 index e69de29bb..000000000 diff --git a/nova/tests/README.rst b/nova/tests/README.rst new file mode 100644 index 000000000..76b92258a --- /dev/null +++ b/nova/tests/README.rst @@ -0,0 +1,78 @@ +===================================== +OpenStack Nova Testing Infrastructure +===================================== + +This README file attempts to provide current and prospective contributors with +everything they need to know in order to start creating unit tests for nova. + +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 Exceptions +-------------------- +A properly written test asserts that particular behavior occurs. This can +be a success condition or a failure condition, including an exception. +When asserting that a particular exception is raised, the most specific +exception possible should be used. + +In particular, testing for Exception being raised is almost always a +mistake since it will match (almost) every exception, even those +unrelated to the exception intended to be tested. + +This applies to catching exceptions manually with a try/except block, +or using assertRaises(). + +Example:: + + self.assertRaises(exception.InstanceNotFound, db.instance_get_by_uuid, + elevated, instance_uuid) + +If a stubbed function/method needs a generic exception for testing +purposes, test.TestingException is available. + +Example:: + + def stubbed_method(self): + raise test.TestingException() + self.stubs.Set(cls, 'inner_method', stubbed_method) + + obj = cls() + self.assertRaises(test.TestingException, obj.outer_method) -- cgit