Jump to: navigation, search

Difference between revisions of "Testr"

 
Line 2: Line 2:
 
= testr =
 
= testr =
  
testr is a test runner runner and is part of testrepository. testr works by using your test runner to list all of your tests, it takes this list and partitions it into a number of partitions matching the number of CPUs available on the current machine, then forks that number test runners giving each one their own partition of the test list. The test runners are expected to speak subunit back to testr so that testr can keep track of test successes and failures along with other statistics.
+
testr is a test runner runner and is part of testrepository. testrepository has excellent [[documentation|https://testrepository.readthedocs.org/en/latest/]] and a very useful [[manual|https://testrepository.readthedocs.org/en/latest/MANUAL.html]]. This wiki page will try and condense much of the info found there. testr works by using your test runner to list all of your tests, it takes this list and partitions it into a number of partitions matching the number of CPUs available on the current machine, then forks that number test runners giving each one their own partition of the test list. The test runners are expected to speak subunit back to testr so that testr can keep track of test successes and failures along with other statistics.
  
 
TL;DR testr will run your tests in parallel (so they go faster) and it keeps robust logs of the results.
 
TL;DR testr will run your tests in parallel (so they go faster) and it keeps robust logs of the results.

Revision as of 18:00, 17 December 2012

testr

testr is a test runner runner and is part of testrepository. testrepository has excellent https://testrepository.readthedocs.org/en/latest/ and a very useful https://testrepository.readthedocs.org/en/latest/MANUAL.html. This wiki page will try and condense much of the info found there. testr works by using your test runner to list all of your tests, it takes this list and partitions it into a number of partitions matching the number of CPUs available on the current machine, then forks that number test runners giving each one their own partition of the test list. The test runners are expected to speak subunit back to testr so that testr can keep track of test successes and failures along with other statistics.

TL;DR testr will run your tests in parallel (so they go faster) and it keeps robust logs of the results.

Using testr

Nova is the only OpenStack project to currently use testr (we ported the hard project first). To use testr with Nova you can use the existing wrappers, tox and run_tests.sh.

tox -epy27
# or
tox -epy26
# or
tox -ecover
# or
run_tests.sh

Will all run Nova's unittests with testr. You can specify which tests you want to run with a regex (the regex is over the full path of the test eg nova.tests.test_something.TestSomething.test_this_one_unit):

tox -epy27 -- test_name_regex
# or
run_tests.sh test_name_regex


testr can be quite useful when run directly as well. First source your test venv.

source .tox/py27/bin/activate

With the venv sourced we can run testr directly.

testr help

testr run --parallel
testr run --parallel test_name_regex

After tests have run you can view the failing tests then run only that list of tests.

testr failing
testr run --failing


Test Logs

You will find that testr keeps test logs in .testrepository/$TEST_RUN_NUMBER. These logs are subunit streams and are used to determine which tests are failing when you run testr failing. There are a couple neat consequences of this, you can pass these logs around to collaborate on a set of failing tests, it is really easy to write scripts that parse and transform the logs (see python-subunit and its subunit parser), and you can use the logs to help reproduce errors by using the log feed the testr test list fed to the test runners.