Comments on: Test Driven Development in Python

By: Jacob

Jacob — Fri, 06 Feb 2009 18:48:35 +0000

The workflow I’m suggesting is a bit different: write the doctests in the docstring at the same time you write the code, then run it to see if you get the expected results. I see doctests as hitting two birds with one stone: working tests plus free documentation.

By: foo

foo — Fri, 06 Feb 2009 17:59:25 +0000

I’d say the natural workflow for doctests is demonstrate the use of a module in interactive interpreter and just copy-paste the results as documentation. TDD beats the purpose of this free documentation, and thus other testing methods might be more appropriate.

By: Jacob

Jacob — Fri, 06 Feb 2009 16:47:37 +0000

I agree with your points about doctests as documentation. In my experience, there’s many times when those are all the tests you need. If the doctest examples run, then you don’t need to write any extra unit tests. And for those cases of simple input-output functions, doctests can be integrated into your TDD practices.

By: oblivious

oblivious — Fri, 06 Feb 2009 07:49:32 +0000

TDD is great, but nosetests, not doctest, is the way to go for that.

I love doctest, but I don’t think anybody should be using it for TDD. The syntax gets tricky for embedded strings, and it gets awkward if you need to refer to module globals.

doctest is for literate, reliable documentation. The worst kind of doc is one that is no longer true. With a doctest example, the reader knows that the docs are still correct since the doctests still pass. It also enforces a uniform standard for displaying examples, which improves readability. So don’t stop using doctests, but try something else for TDD.