Package: olstests
.. -*- Mode: rst -*-===========ols.tests===========This project provides a central place for utilities common to many use casesso we don't have to re-implement them for multiple projects.It builds on techniques used for many years in lp:bzr, lp:testtools,lp:subunit, lp:selenium-simple-test, lp:u1-test-utils and of course pythonunittest itself.Test Loaders============The provided test loader standardizes on test IDs and addresses current andknown issues with unittest discover.It can be used to load arbitrary tests from an arbitrary tree, relying onsimple hooks defined in python packages.Examples include lp:selenium-simple-test scripts, shell scripts as well aspython tests organized in unusual ways. It also allows mixing differentkinds of tests in the same tree.The emphasis is on allowing the user to fully customize test loading.Test suites===========There are times where a test suite needs a specific setup. Thesuites.TestSuite class implements setUp()/addCleanup() with semanticssimilar to the sibling functions in unittest.TestCase.This should be used while loading the tests and relies on existing API forthe test result classes.Test selection==============While a test suite is most commonly run in full, there are times when only asubset of a suite needs to run:* a developer may want to focus on a very reduced set when fixing a bug ordeveloping a new feature.* a CI engine may want to run only hardware specific tests or any specificconfiguration (network, file systems, OS).Using regular expressions to select or exclude tests has been addressing allthese needs in a surprisingly easy way.Test runners============See test results ;)Test runners generally mix test loading, test selection and test resultsproduction.ols-tests aim is not to provide a one-size fits all test runner but insteadallow people to use their preferred one or define their own by offeringcustomizable test loaders, test filters and test results.''ols-run-tests'' is a simple test runner that demonstrates how to use thevarious pieces. It may or may not address your needs ;)Test Results============Test results are the output interface of test runners.The most common use is to display the IDs executed and their timings as wellas arun summary. It is good enough for interactive use or to providefeedback during remote execution.subunit is used when collecting test execution related data is needed (mostimportantly failures), this project focuses on *testing* the integrationwith subunit but also exposeTest fixtures=============A common pattern in implementing TestCases is to add fixtures in the baseclass so they are accessible to all tests. This pollutes the base classeswith methods or attributes not used by most of the tests.Fixtures are better used via composition. But requiring an additional'.fixtures.feature_x.attribute_y' make them harder to use.We use a middle ground here by just using a simpler (and a bit surprising atfirst) syntax and using python's ability to handle arbitrary attributes.Apart from that modest invasise use of test objects namespace, the onlyconstraint is that the test object supports the 'addCleanup' and the mostusual assertX methods. Since 'addCleanup' is provided by unittest.TestCaseitself, this is a light constraint, most python test frameworks inheritingfrom it.The benefit is that these fixtures can be used on any TestCase class withoutrequiring inheritance which can then be used for other needs withoutinterferences.