There must be something in the air: two bloggers are talking about two alternatives to the standard Python unittest module:
- Phillip Eby glowingly reviews doctest, which lets you write runnable code in docstrings, and then execute them all as unit tests.
- Ian Bicking likes py.test, a lighter-weight alternative to unittest.
I’ve been writing unit tests for my Python projects, and I am definitely hooked. The feeling of having the correctness of my code pinned down by extensive unit tests is a great security blanket. I can’t imagine working without them (except at work, grrrr...). And I’ve had my own difficulties with unittest, so I’m interested in other possibilities.
I haven’t tried doctest, and it seems very clever and cool, but I can’t see it working out in the long run. The needs of documentation and tests are different, and they will necessarily diverge. For one thing, documentation ideally should be concise, and tests ideally should be exhaustive. And not all methods can be well documented by showing execution examples.
In fact, the PyCon talk about doctest admits to some of these difficulties, and recommends creating functions whose only purpose is to carry docstrings full of tests. To me, this is an admission of failure. Maybe I’m being too harsh and should give it a try.
As to py.test, I’ll definitely have to look into it. It seems like unittest, but written Pythonically from the start, rather than ported from Java.