Same guy further down the blog, which I think gives a fairer presentation of his position: "TDD is the way to go, I’m absolutely sure of it. It brings more ben

Same guy further down the blog, which I think gives a fairer presentation of his position: "TDD is the way to go, I’m absolutely sure of it. It brings more benefits than you might first think. As well as the simple fact that your code will be more reliable, it forces you to write your code in a way that is testable, which in turn will make it loosely coupled and modular. It forces you to think about what you want your code to do before you start writing it. It brings other additional benefits that I won’t bother to mention, suffice to say theres no excuse for not using it in modern development. [...] In short unit tests will be more hinderance than help if there is a lot of prototyping and learning in your application. In cases like this your best doing away with the tests and just writing the code. Wait until your code starts to stabilise and then go back and review the situation then. As much as unit tests give you flexibility by allowing you to change code quickly with more assurance that you won’t break anything inadvertently. It can also really slow down prototyping and rapid development if you don’t have an understanding of your environment. The reason I mention this is so many tutorials and advice on the internet tell you to not write a line of code until you’ve written a test. I think you need to be a little more pragmatic about it." http://mat-mcloughlin.github.io/2013/05/16/when-you-shouldnt-test.html http://mat-mcloughlin.github.io/2013/05/16/when-you-shouldnt... The problem I have strong advocacy for TDD is the same problem I had for strong advocacy for OOP, and which the fella above seems to some extent familiar with: It's good if you don't have a deeper understanding of the subject but in the long run slavish adherence to a paradigm will cripple your ability to do things. This is exacerbated by the fact that, in the short run, you probably won't want to use the tests unless you understand why they'd be good - and if you understand why they'd be good, then just go ahead and write the program that way in the first place and save yourself a bunch of time. The key fact with relation to the original article here is that he didn't see any of these advantages in TDD until he want to a speech where someone told him to do TDD another way and pointed out the advantages. Which rather implies that the advantages aren't a result of TDD as much as they are the result of already knowing something and levering it into a TDD framework...