Interestingly, this example is one of my counter-arguments for how TDD isn't applicable.<p>You have a function "sort(numbers)". You have a set of pre- and post-conditions; in this case the documentation lists the post-conditions and in TDD it's done through test exemplars.<p>But the author writes "Next, you can write actual code, then tests since you know clearly what you are going to code." This is rather incorrect. You know what your goals are, but not how you want to achieve it.<p>Are you going to implement Shell sort? Quicksort? Timsort? Your tests and your API documentation should not be so dependent on the implementation that you can't replace one with another (so long as certain performance requirements are met). But that means the *DD techniques don't clearly describe 'what you are going to code next.'<p>There are any of a number of algorithms with a similarly simple API but with complex implementations; substring search for one, and one I just did is graph canonicalization.<p>Here, btw, is a 2011 PyCon talk on Documentation Driven Development: <a href="http://blip.tv/pycon-us-videos-2009-2010-2011/pycon-2011-documentation-driven-development-4896872" rel="nofollow">http://blip.tv/pycon-us-videos-2009-2010-2011/pycon-2011-doc...</a>