This document provides an overview of tools and techniques for testing Python code including: 1) virtualenv for creating isolated Python environments, nose for test discovery and less boilerplate than unittest, and doctest for executing code samples. 2) Mock for replacing real objects with mock objects to make assertions about method usage, and coverage for generating test coverage reports. 3) Metrics for test quality including count, code length ratio, and coverage percentage.

1. Testing Workshop
Author: Michael Dunstan
<michael@elyt.com>
Version: 1.2
Licence: Creative Commons
Attribution-Share
Alike 3.0

2. Other hands-on
introductions to testing
Chapter 9: Unit Testing of Dive Into Python 3 by
Mark Pilgrim
Introduction to unittest - Starting Testing with
Python by Michael Foord
Dingus Screencast: A mock/stub library with
automatic isolation by Gary Bernhardt.

3. virtualenv
Provides a nicely isolated Python environment
for running the demonstration.
Installation the virtualenv tool:
$ easy_install virtualenv
Create an isolated Python environment:
$ virtualenv --no-site-packages test-demo
Activate this new environment:
$ source test-demo/bin/activate
Using version 1.4rc1 of virtualenv.

4. nose
Test discovery, loading and running.
Customisable through the use of plugins.
Less boiler plate code than unittest.
Installation:
easy_install nose
Minimal test:
from nose.tools import assert_equals
def test_simple_addition():
assert_equals(1+1, 2)
See Testing with nose.
Using version 0.11.1 of nose.

5. FizzBuzz
Exercise: play the FizzBuzz game. Write a program
that:
Prints the numbers from 1 to 100.
But for multiples of 3 print "Fizz" instead of the
number.
And for the multiples of 5 print "Buzz".
For numbers which are multiples of both 3 and 5
print "FizzBuzz".

6. Short life cycle highly
repeated

7. NoseGrowl
Example of using a nose plugin.
Hooks into system wide notification tool. Growl
on OS X.
Installation:
easy_install NoseGrowl
Usage
nosetests --with-growl

8. setup.cfg
Put all your regular command line options into a
config file setup.cfg:
[nosetests]
verbose=True
with-growl=1

9. doctest
Execute code samples:
>>> a = 1
>>> b = 2
>>> a + b
3
Include doctests in test runs using:
[nosetests]
...
with-doctest=True
doctest-extension=txt
Which also picks up doctests from files such as
README.txt
See doctest.

10. doctest options
Inline comments in the doctest:
>>> print('Hello world') #doctest: +ELLIPSIS
Hello ...d
Other useful options include:
#doctest: +REPORT_UDIFF
#doctest: +NORMALIZE_WHITESPACE
See doctest - Option Flags and Directives.

11. doctest warts
Yikes:
>>> 0.03
0.029999999999999999
>>> {'a': 1, 'b': 2, 'c': 3}
{'a': 1, 'c': 3, 'b': 2}
See Narrative tests are lousy unit tests and Tests are
code, doctests aren't.
However I like doctests.

12. FizzBuzz 1.1
For the number 9 print the current time and date.
This is a forced example to demonstrate the use
of mock.

13. mock
Replace real objects used by your code with
mock objects.
Mock objects can be configured to respond in
specific ways.
After performing an action, you can make
assertions about which methods / attributes were
used and arguments they were called with.
The important thing with patching is that you
patch the namespace where the object is used and
not where it is defined.
Installation:
easy_install mock
See Mock - Mocking and Testing Library.
Using version 0.5.0 of mock.

14. coverage
Installation:
easy_install coverage
Generate coverage data:
nosetests
--with-coverage
--cover-html
--cover-package fizzbuzz
Then view the coverage reports:
open cover/index.html
Using version 3.1 of coverage.

15. Test metrics
Total test count — more tests are better.
LOC for application code verses LOC for the
tests.
SQLite is currently claiming 709 times as much
test code and test scripts than the application
code base itself. See How SQLite Is Tested.
Test coverage — larger coverage is better.
But 100% coverage only means that you have
reached the end of the limits of the coverage tool.

16. FizzBuzz code
See http://bitbucket.org/dunny/fizzbuzz/src/