testtools is a set of extensions to the Python standard library’s unit testing framework. These extensions have been derived from many years of experience with unit testing in Python and come from many different sources.
What better way to start than with a contrived code snippet?:
from testtools import TestCase
from testtools.content import Content
from testtools.content_type import UTF8_TEXT
from testtools.matchers import Equals
from myproject import SillySquareServer
class TestSillySquareServer(TestCase):
def setUp(self):
super(TestSillySquareServer, self).setUp()
self.server = self.useFixture(SillySquareServer())
self.addCleanup(self.attach_log_file)
def attach_log_file(self):
self.addDetail(
'log-file',
Content(UTF8_TEXT,
lambda: open(self.server.logfile, 'r').readlines()))
def test_server_is_cool(self):
self.assertThat(self.server.temperature, Equals("cool"))
def test_square(self):
self.assertThat(self.server.silly_square_of(7), Equals(49))
Why use testtools?
Matchers: better than assertion methods
Of course, in any serious project you want to be able to have assertions that are specific to that project and the particular problem that it is addressing. Rather than forcing you to define your own assertion methods and maintain your own inheritance hierarchy of TestCase classes, testtools lets you write your own “matchers”, custom predicates that can be plugged into a unit test:
def test_response_has_bold(self):
# The response has bold text.
response = self.server.getResponse()
self.assertThat(response, HTMLContains(Tag('bold', 'b')))
More debugging info, when you need it
testtools makes it easy to add arbitrary data to your test result. If you want to know what’s in a log file when a test fails, or what the load was on the computer when a test started, or what files were open, you can add that information with TestCase.addDetail, and it will appear in the test results if that test fails.
Extend unittest, but stay compatible and re-usable
testtools goes to great lengths to allow serious test authors and test framework authors to do whatever they like with their tests and their extensions while staying compatible with the standard library’s unittest.
testtools has completely parametrized how exceptions raised in tests are mapped to TestResult methods and how tests are actually executed (ever wanted tearDown to be called regardless of whether setUp succeeds?)
It also provides many simple but handy utilities, like the ability to clone a test, a MultiTestResult object that lets many result objects get the results from one test suite, adapters to bring legacy TestResult objects into our new golden age.
Cross-Python compatibility
testtools gives you the very latest in unit testing technology in a way that will work with Python 3.10+ and PyPy3.
If you wish to use testtools with Python 2.4 or 2.5, then please use testtools 0.9.15.
If you wish to use testtools with Python 2.6 or 3.2, then please use testtools 1.9.0.
If you wish to use testtools with Python 3.3 or 3.4, then please use testtools 2.3.0.
If you wish to use testtools with Python 2.7 or 3.5, then please use testtools 2.4.0.
Release files for testtools 2.9.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| testtools-2.9.1.tar.gz | 221.4 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| testtools-2.9.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 331.7 kB
Release files / testtools-2.9.1.tar.gz
| Download URL | testtools-2.9.1.tar.gz |
|---|---|
| Size | 221.4 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
39ad9eb9e1b935d6838f4b3aee4d6e72db65df5602f6feda998dbb4fe8de0b19
|
|
BLAKE2b-256 checksum How to use checksums |
8b80af955640b4e8348aaa8026f9f48304811ec3342d9928ddb611d38a190ea0
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Apr 24, 2026.
Transparency logRelease files / testtools-2.9.1-py3-none-any.whl
| Download URL | testtools-2.9.1-py3-none-any.whl |
|---|---|
| Size | 110.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
faf2d689b3614d87459f7f715fc8349a3f77a252486b104d0cfe635b44326895
|
|
BLAKE2b-256 checksum How to use checksums |
f45f80ea589bc04651ea10c0f53da06cb0ac33b616b0ec78bf7dc8d8fd642f5d
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Apr 24, 2026.
Transparency log
