Course 3.2Lesson 2 of 5

The unittest module

The unittest module is Python's standard tool for tests. A test class inherits from unittest.TestCase, each method whose name starts with test is a test, and the assert methods such as assertEqual, assertAlmostEqual, assertTrue and assertRaises check the results and give a clear report when they fail. setUp runs before each test, so that every test starts from a fresh state. unittest.main runs all the tests and prints a dot for a pass, an F for a failure and an E for an error, then a summary. A test should check one thing and have a name that says what it checks. Use assertAlmostEqual for decimal numbers, and assertRaises with a with block for an expected error.

about 25 min1 simulation2 practice questions

Lesson 2 of 5Show all lessons

Try the code and the simulations beside the lesson.

What you will be able to do

After this lesson you can

write a test class with unittest.TestCase,
use assertEqual, assertAlmostEqual, assertTrue and assertRaises,
read the report of a test run, and
use setUp to give every test a fresh start.

From a table to a tool

A table of tests is simple and good. For bigger programs, programmers use a test framework: a tool that finds the tests, runs them, and reports in a standard way. Python has one in its standard library: unittest.

Predict first. There are seven tests. One of them is wrong on purpose. Which one fails, and how does the report show it? Then run it.

Read the program.

- A test class inherits from unittest.TestCase: class TestGrade(unittest.TestCase):.

- Each method whose name starts with test is a test. Python finds them by the name. The name should say what it checks: test_edges, test_empty.

- The assert methods compare and report. self.assertEqual(grade(100), "A") passes when the two are equal. If not, it fails, and the report shows both values. This is better than a plain assert.

- assertAlmostEqual compares decimal numbers with a small allowance. Use it for decimals. 0.1 + 0.2 == 0.3 is False, but assertAlmostEqual(0.1 + 0.2, 0.3) passes.

- assertRaises checks that an error happens: with self.assertRaises(ValueError): average([]). If no ValueError is raised, the test fails. Testing that the error is raised is as important as testing the answers.

- setUp runs before each test. It gives every test a fresh start, so that one test cannot disturb another. Here it makes the list of marks.

- unittest.main(...) runs everything. We write exit=False so that the program does not end the session.

Reading the report

The output looks like this:

text

.......F  (one letter for each test)
======================================================================
FAIL: test_a_wrong_expectation (__main__.TestAverage...)
----------------------------------------------------------------------
AssertionError: 2.0 != 3

Ran 8 tests in 0.001s

FAILED (failures=1)

A dot is a pass. F is a failure: the test ran and the answer was wrong. E is an error: something went wrong in the test itself, for example a crash.
Each failure is listed with the name of the test and the two values that were compared: 2.0 != 3. That is the answer of the function, and the expected answer.
The last line says OK, or FAILED with the numbers.

In our program, average([1, 2, 3]) is 2.0, and the test wrongly expected 3. This is a failure of the test, not of the function: a reminder that the expected answers must be right, too.

Use assertAlmostEqual for every answer that comes from decimal arithmetic. The default, 7 places, suits most programs.

What makes a good test

One idea in each test. If test_edges fails, you know what to look at. A test with twenty asserts does not say which one matters.
A clear name. test_empty_list_raises says everything.
Independent. A test must not depend on another having run first. That is what setUp is for.
Fast. You will run the tests very often.
Tests for errors too. assertRaises for each way that the function should refuse.

unittest or a table?

	Table of tests	`unittest`
Short to write	yes	a little longer
One report with all failures	with your loop	built in
Shows both values	with your print	built in
Checks for errors	with `try`	`assertRaises`
Runs only some tests, or in a big project	by hand	built in

For a small script, a table is fine. For a project that grows, use unittest (or pytest, a popular tool that you may meet later).

Common mistakes

A test method whose name does not start with test. It is never run.
Comparing decimal numbers with assertEqual. Use assertAlmostEqual.
Tests that depend on each other.
Forgetting self. before assertEqual.
Forgetting the with in assertRaises.
A wrong expected answer in the test.

Practice

Start with two quick questions. Each New numbers gives you a fresh one, so you can practise as long as you like.

Then the labs and the problems:

Warm-up. Open the problem Name the test and the problem Read the report.
Build. Open the lab Test a function with a table. You write a function that runs a table and gives the failures, and the checker tries it on good and bad functions.
Stretch. Write a test class for the BankAccount of the course on classes.

Remember these

A test class inherits from unittest.TestCase. Methods that start with test are the tests.
assertEqual, assertAlmostEqual, assertTrue and assertRaises compare and report both values.
setUp runs before each test.
In the report, a dot is a pass, F is a failure, and E is an error.
One idea in each test, with a clear name.