Untested code is broken code

Note

Some of this stuff is awesome and I use it every day. The doctest stuff led me astray and I’m glad to be free. (Danny 07/05/2011)

by Martin Aspeli and Philp von Weiterhausen

arguments against

• they take time to write
• I’m a good developer
• my customer/community does the testing

justification

• You rarely catch subtle problems
• put the time you spend writing silly bugs into writing tests
• you end up saving time when you refactor

tests in python

• Easy, especially in Python

Test driven development

• Write the test first
  • You don’t forget to write the tests
  • You can catch design mistakes early on

Executable documentation

Note

This section was designed to support doctests. Now I advocate unittests, sphinx, and rtfd.org (Danny 07/05/2011)

• Tests should excercise APIs, demonstrate how to use them
• Developers may find documentation in tests
• Why not turn them into documentation?

doctests

Warning

Use doctests and you’ll hate yourself later, I’m keeping this for the sake of history (Danny 07/05/2011)

• looks like an interpreter session
• restructured text - can be rendered to HTML, PDF, etc

documentation-driven development

• write unittests first
• science fixture
• tell a story to an imaginary user
• use ‘we’ and ‘you’
• put the story on the product home page!!!
• Danny likes this idea tons!

General Test concepts

• Each test should be totally independent of other tests
• Only load the bits you need, don’t load all components! So…
  • Use zope.component.provideAdapter(UpperCaser)
  • zope.testing.doctest.DocFileSuite(..,…,..,teardown=True)
  • $instance test
• Don’t use: from Testing import ZopeTestCase unless you are doing integration
• from Products.Five.testbrowser import Browser
  • Simulates browser actions
  • learned in the class