Ask HN: Help me see why everyone seems to love TDD?

As a personal rule, for every 1 minute I spend doing something, I make sure to spend 5 minutes thinking about what I'm doing. Does my intended solution solve the problem? Is it missing anything? Does it introduce any new issues? Does it solve the problem, but lead the code down a bad or inflexible road?

Writing and shipping code fast can be tempting, but that speed often impairs insights of what that code actually does, or what implications the code may have down the road. Spending more time thinking than doing might seem less productive, but that is only true in the context of immediate results; in the long run, being considerate and deliberate with your code will have huge payoffs.

The major benefit of TDD is that it forces developers to think about their code before writing any of it, and later reap the fruits of that deliberation. If you do that thinking anyway, without needing TDD, then the process (writing tests first) might not be as practical for you.

As with all things, it comes down to knowing your own limits, and using tools and processes help soften those limits.

If you're trying to "sell" it to your manager, keep that same thing in mind. What problems does the company experience regularly that would be solved or minimized by TDD? If the company gets along fine without it, then TDD might not be necessary. When pitching it, be sure to have actual, relevant facts ready: How many bugs make it to production? How often is a feature requested, but existing code makes it difficult to implement? Do people often find themselves asking "I wish I had thought of that earlier"?

Ended up with about 200 tests.

As things go, specs changed and part of this application had to be rewritten. Most of the tests started to fail, not because the code was wrong, but because they tested for different spec. So I needed to rewrite all those unit tests again.

Sure, I catched "some" refactoring bugs, but most failed tests weren't bugs, just tests that became wrong. This made me question the whole TDD approach in production.

TDD is (among other things) a way to have developers write formal (as in "machine readable") specifications for particular features of a computer program, _ahead of time_. It does this without bothering the developer with intangible (abstract, not-part-of-the-syntax-of-programming-language) late-undergraduate CS concepts like "invariant", "pre-" and "postcondition" etc.

This makes the test not only an affirmation of feature compliance, but a _reasoning tool_ in and of itself. Since tests are specifications written in the target application language and even run in the same runtime, tests can serve the dual purpose of reasoning about the abstract logic of the application as well as the implementation details of the chosen toolchain.

Now, bugs in either tests or toolchain will affect the test results, so while you can kill two birds with one stone, you might break a window in the effort. You now have to make tests for the tests and turtles all the way down.

Terrible idea.

> and hire people to write automated integration tests.

Excellent idea.

I've been a part of many software projects, and unfortunately almost none of them took testing seriously enough. No, actually, none did.

I've tested software manually for years. I've found many defects I'm certain no reasonably complex automated test would have detected, because finding them was down to my global knowledge of the entire system's state or the superior ability of humans to detect patterns.

Don't underestimate what an experienced, cunning tester will suss out.