TDD is Behavior Specification

I had a very similar outlook.<p>However since I have been doing a lot of development for cloud platforms (Google App Engine for instance), I have realized that without tests you don&#x27;t really have a sane way of debugging and verifying your code.<p>And since I always write a lot of code during my work (testing stuff out in python shell) I have realized how wasteful my previous approach was.<p>If I had written that code into a file and added a couple of assertions I would have a nice test suite.<p>However I still believe that on should not overdo tests from the get go. Write the tests for common cases, then add regression tests as bugs pop up here and there.<p>That gives the best ROI IMHO.<p>Edit: I have to confess that indeed I have read the TLDR; then the first paragraph and then I was already writing a comment here.<p>For the record I think that cargo cultists are going to be cargo culting no matter how we call this or that.

&gt; Asking people to write tests before they write code is like asking them to test-drive a new car before it even exists. This isn’t possible.<p>This is an incredibly bad analogy that really doesn&#x27;t stand up. You <i>can</i> write tests before you write the implementation of them, to define how you want the end result of your program&#x27;s interfaces to look. The rest of the article arguing the semantics behind calling them <i>tests</i> or <i>specifications</i> doesn&#x27;t add anything but confusion to the testing discussion.<p>This:<p>&gt; Calling tests specifications makes the concept more intuitively available in several ways.<p>Is entirely subjective.

Isn&#x27;t this basically what Dan North and Chelimsky said when they started the BDD movement? Is TFA intended to be merely a restatement of the BDD concept from circa 2007? Or is it saying something more that I overlooked?

In a nutshell, he&#x27;s saying to call it &quot;specification driven development&quot;, since you are writing specifications for the code before it exists.

I&#x27;m often frustrated with developers looking at the term &quot;test-driven development&quot;, focusing on the word &quot;test&quot;, and thinking of TDD as a testing process instead of a development process. The BDD movement made some progress on this front, but it still seems to be a problem. Maybe calling it &quot;specification-driven development&quot; is the next step.

TDD is a great way to take the fun out of software development.