Test-Driven Development is Stupid

Which is why testing behaviour not implementation is so important. Admittedly this sounds easier than it is in practice. Personally I've found that in-memory coarse-grained tests more akin to integration tests, that test from the outside in are helpful and easier to maintain because they tend to be less concerned with the how. I can then choose to write finer-grained unit tests where appropraite

There is no such thing as bug-free app, and I do not agree for 100% code coverage (rather write test for what's important to you, i.e. prioritise). However, tests gives you a higher level of confidence when you perform refactoring.

PS. Regression is far worse than momentum against change, when your app is `broken` you can't deliver it.

When I read these kind of articles I'm always curious to see the professional background of the author. Not to criticize, but to see if he/she's talking about something he/she saw in scale or not. Because if you're working with a very small code base then I may even understand sentences like "I am against unit tests in general". I've never met people who work (or worked) in very large companies being against, at least, unit test. Where hundred/thousands of people touch the same code .. not having unit tests, in the long term, is a suicide.

I work somewhere without any unit tests at all, and he still lost me at that sentence.

If he thinks test driven development can produce horrible implementations then he's right, they can. But he's horribly wrong that the solution is to abandon unit testing.

Without unit tests developers begin to live in fear of parts of the code, and refuse to clean it up "in case it breaks something", and there's no way to verify those fears aren't founded.

Any refactoring job starts with annoying a lot of people by breaking things that previous worked and questions start to appear from people that "it used to work before" when some of those breakages slip through to the customer.

Refactoring becomes something to fear because "we'll have to retest everything" which is a large expense that cannot be afforded.

The "problem" with TDD is that it can only tell you that your expectations have been met. It can't tell you if you are doing the right thing. Only that the things you guessed at are working in the way you decided they should work.

If, on the other hand, your problem is not very well defined, then your tests have a good chance of eventually becoming a liability. If you ever discover that your domain model, interfaces, or even selection of algorithms are insufficient (or just plain wrong), it's more likely that your pre-existing test code will be unusable, rather than the sort of guide for refactoring that they're touted to be. If you had guessed at the interface or algorithms correctly, but merely implemented them incorrectly, yes, the tests will guide you back to correctness, but I think that tends to be a big "if". Given that you don't understand the problem, the likelihood that you've made mistakes in the design are high.

Of course, this isn't the fault of TDD, that's exactly what it's meant to be. The problem is in people thinking that is equivalent to verification.

TDD is ultimately a design tool, one that is useful in cases where we have a very good idea of constraints and requirements of a problem, on where the problem is very, very well defined.

And that's why I say it's a code-smell. The problems that are well-defined are often that way because several people have created several implementations of it already. If I'm TDDing something, it usually means I'm rewriting code that already exists somewhere.

Now, I might have good reason to do that. Perhaps I have constraints that nobody else has ever considered. I generally hate the phrase "don't reinvent the wheel". I can think of at least 3 times off the top of my head that the wheel was successfully and usefully reinvented in the 20th century alone. But it's very important that you understand that is what you're doing. If you are aware you're reimplementing a known solution, you can now choose to study your forebears and get an even better understanding of the problem.

Personally, I think saved REPL sessions are better than TDD for problems that are not very well understood or well defined. If I were to try to build an MPEG encoder in JavaScript (for whatever reason), I'd certainly use TDD, because MPEG encoders have specifically well-known inputs and outputs. But if I am trying to invent a completely new UI paradigm for virtual reality, then TDD is just not an applicable tool.

Also, it's a lot easier to tell myself to just discard a saved REPL session that ceases to be valuable after a major rethink in how the problem works than it is to discard tests. Plus, I find them to be a little more informative in terms of demonstrating behavior to other developers than test code.