> TDD forces you be clear about what the result of your code should be before you start coding ... which is often difficult and inefficient. A large part of th

> TDD forces you be clear about what the result of your code should be before you start coding ... which is often difficult and inefficient. A large part of the point of the article is that when making changes to an existing system, you often DON'T know until doing some experimentation what the result of your particular new bit of code should be. You know what change you want to happen to the behaviour of the system as a whole, but don't yet understand how the pieces that make up the system slot together. That permits you to dive in and try making changes and see what their effect is, but doesn't permit you to write a unit test right away. > it is smarter and more effective to write them first. But... why? You're asserting this without any justification. > People who say that TDD moves slower are simply admitting that they don't test. This accusation is pretty tedious. The article was explicitly comparing the test-first-code-second approach against the code-first-test-second approach and giving a reasoned argument (which you've not acknowledged or engaged with) for why the second was usually superior. The author isn't saying they don't test or arguing for not testing. > I found it rather ironic that the article ends by praising behaviour-driven development That was sarcasm.