I don't think saying anything negative about test driven development is a positive contribution. Our industry should practice it more instead of less. I do it a

I don't think saying anything negative about test driven development is a positive contribution. Our industry should practice it more instead of less. I do it almost all the time. Sure, there are a few exceptions. It is quite unneeded for at throw-away script, obviously. If something is in a user interface and it is purely visual it may be better to write the code first because the browser in your head might not be good enough to write a correct test beforehand. Those are the exceptions, though. For any program containing somewhat complex logic TDD is king. There is nothing that beats it in terms of reliability and after some time also regarding speed because in the end nothing costs more time than something that keeps breaking in production. Thorough manual testing is also quite expensive in terms of time. I note some people here are talking about things that require exploration and research as a counter-inducation. Well, maybe in some cases but certainly not in all. One could also start with a test at a relatively high level and then do the exploration while writing code to make it pass. In that case one would write more code to make it pass than would be normal but it still benefits from being in the TDD cycle. After having it basically working one does additional TDD cycles to iron out the cases where it would go wrong. The main benefits of starting out with a test is that: 1) tests do cost time so you need to recoup that by going faster in other parts of development. If you start out with the test it immediately starts paying back when it flags your first attempt at an implementation as either passing or failing. 2) The fact that the test first should fail and fail in a particular way tells you whether your thinking about how the system works is actually correct. It is like bringing the scientific method to programming. People in practice very often have just the wrong idea of how something works in the first place. People are also talking about TDD being a strange order to think about programming. This is also my experience. It requires some getting used to. It is quite good though. The point being that it enables one to not need to think about everything at the same time. When writing a test you think about the functionality you need. When writing an implementation you think about algorithms and when refactoring you think about code quality. In traditional development this gets rolled up in one big ball of mud which makes the thinking about either of these three aspects of lower quality. One thing that people get into trouble with is trying to write test for functionality that is too low level and therefore very much implementation defined and therefore subject to change. I think one should generally work at a level where one tests the behavior of a cluster of a few classes. This problem also leads to tests that are too trivial. If one has a method that adds n to m and one writes a test for that one is testing that the processor really can add numbers and that is not very interesting.