Untested code is broken code

Plone conference 2007, Naples. Speakers: Philipp von Weitershausen and Martin Aspeli

"I know I should write tests, but I will just let my customer or the community do that for me. They should just report bugs." Not a good idea, especially if your app only fails in some code that only gets executed by your boss. He will not be happy if it fails.

So first write a test, then start coding. That is Test Driven Development (TDD). Core developers should know that and should not need to follow this talk. :)

With TDD you catch design mistakes early on. It can keep your code simple: if the tests all pass, why would you add more code because you think you might need it in the future, complicating the code?

Tests should exercise API. Demonstrate how to use them. Other developers are happy with this kind of tested documentation. You do this with doctests. They look like a python interpreter session with some paragraphs in between. We use restructured text, so it can be turned into html and pdf and is still readable on its own.

We also have Documentation Driven Development (DDD). You write doctests first. You write a science fiction story. You tell it to an imaginary user. Just use the words "we" and "you". You can put that story on the product homepage (plone.org, PyPI). It helps you keep in mind who you are actually talking to, instead of making documentation that only you or some core developers can understand.

Now Martin Aspeli gave a demo. He just wrote to the attendees list giving some links. I am sure he will not mind if I quote him here so others can read it too:

I've checked in the examples to my two talks in the collective:

- http://svn.plone.org/svn/collective/examples/policy-buildout/ contains the sample code for the "Extending and customising Plone 3" talk. The slides are there too, in PDF format.

- http://svn.plone.org/svn/collective/examples/example.tests/ contains boilerplate examples for the different types of tests covered in the "Untested code is broken code" talk, which I gave with Philipp von Weitershausen this morning. This may be useful as it has well-commented test setup examples. I always copy and paste this stuff between my products, so now hopefully we can keep this in one place.