Untested code is
broken code
Martin Aspeli
Philipp von Weitershausen

why tests?

I know I should write
tests, but...
• they take time to write
• I’m a good developer
• my customer / the community does the
testing

find the bug...
class Employee(object):
def __init__(self, name, position, employee_no=None):
self.name = name
self.position = position
self.employee_no = employee_no
salaries = {0: 12000,
1: 4000,
2: 8000,
3: 4000}
def print_salary(employee):
if employee.employee_no:
salary = salaries.get(employee.employee_no, 0)
print \"You make EUR %s.\" % salary
else:
print \"You're not an employee currently.\"

find the bug...
class Employee(object):
def __init__(self, name, position, employee_no=None):
self.name = name
self.position = position
self.employee_no = employee_no
salaries = {0: 12000,
1: 4000,
2: 8000,
3: 4000}
def print_salary(employee):
if employee.employee_no:
salary = salaries.get(employee.employee_no, 0)
print \"You make EUR %s.\" % salary
else:
print \"You're not an employee currently.\"

still asking why tests?
• you rarely catch problems like these with
manual testing
• put the time you waste catching silly bugs,
typos into writing tests
• you end up saving lots of time when you
refactor

tests for print_salary
Employee w/o an employee number is ignored:
>>> print_salary(Employee('Adam', 'Developer'))
You're not an employee currently
Employee w/o a known employee number earns nothing:
>>> print_salary(Employee('Berta', 'Designer', 100))
You make EUR 0.
Employee w/ a valid employee number is found properly:
>>> print_salary(Employee('Chris', 'CTO', 2))
You make EUR 8000.

tests for bugs
• when people report bugs, you want to make
sure you can reproduce them
• when you fix bugs, you want to make sure
they stay fixed

test that exercises the
bug (it fails)
Employee w/o an employee number is ignored:
>>> print_salary(Employee('Adam', 'Developer'))
You're not an employee currently
Employee w/o a known employee number earns nothing:
>>> print_salary(Employee('Berta', 'Designer', 100))
You make EUR 0.
Employee w/ a valid employee number is found properly:
>>> print_salary(Employee('Chris', 'CTO', 2))
You make EUR 8000.
Zero is a valid employee number:
>>> print_salary(Employee('Devon', 'CEO', 0))
You make EUR 12000

making the test pass
class Employee(object):
def __init__(self, name, position, employee_no=None):
self.name = name
self.position = position
self.employee_no = employee_no
salaries = {0: 12000,
1: 4000,
2: 8000,
3: 4000}
def print_salary(employee):
if employee.employee_no is not None:
salary = salaries.get(employee.employee_no, 0)
print \"You make EUR %s.\" % salary
else:
print \"You're not an employee currently.\"

test-driven development
(TDD)

write tests first
• say what?
• I’m serious
• you don’t “forget” to write tests
• you can catch design mistakes early on

executable
documentation

tests and docs
• tests should exercise APIs, demonstrate how
to use them
• developers may find documentation in tests
• why not turn them into proper
documentation?

doctests
• look like interpreter session
• with text paragraphs in between
• reStructuredText
• can be rendered to HTML, PDF, etc.

Interfaces are defined using Python class statements::
>>> import zope.interface
>>> class IFoo(zope.interface.Interface):
... \"\"\"Foo blah blah\"\"\"
...
... x = zope.interface.Attribute(\"\"\"X blah blah\"\"\")
...
... def bar(q, r=None):
... \"\"\"bar blah blah\"\"\"
In the example above, we've created an interface::
>>> type(IFoo)
<class 'zope.interface.interface.InterfaceClass'>
We can ask for the interface's documentation::
>>> IFoo.__doc__
'Foo blah blah'

documentation-driven
development
• write doctests first
• “science-fiction”
• tell a story to an imaginary user
• use “we” and “you”
• put the story on the product homepage
(e.g. plone.org, PyPI)

Martin will now show
some examples for
Plone