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

Most importantly, for a larger code-base, unit tests allow a team to make structural and behavioral changes with much less risk of breaking existing functionality. This is especially true when one has a lot of business and domain rules to maintain. One small code change to core logic can have great impact.

Also, I have a lot of customers to support. Unit tests allow me to have confidence that I won't get 'the middle of the night call'. Largely because of them, my small team is able to work 40 hours a week and focus on adding new value rather than putting out fires.

Unit tests provide self-documentation. When starting to get familiar with new code, I first look for unit tests. If written properly, they provide great examples of primary use cases.

Finally, unit tests allow me to design better systems and interfaces. I can take a class or library and work on it in isolation from other parts of the system. Starting from consumer interface first, I can focus on what is really important and to make that interface much more usable. I can add parts incrementally without worry of breaking that core.

Like most things in software, TDD has trade offs. At first, implementation is much slower, and it requires significant knowledge of unit test best practices. I've seen a lot of bad unit tests: ones that don't test important things, ones that rely on external systems or libraries. I've seen developers get caught in 'unit test paralysis' - where they avoid tackling more important things because they are too focused on testing edge-cases, etc.

There's an entire art to unit testing. It requires pragmatism. For small projects, they're probably overkill. But, when your system grows to have many dependencies, some several years old, and someone has to make a change - ahhh, they're the best.

TDD came out of agile programming which is also more concerned with fast delivery than NASA-style correctness. It's a tool supposed to help you go faster.

If you want an agile unit test suite, it has to run in seconds, not minutes. TDD will make this very clear. If you have problems with the test suite being slow, you have to fix it!

A test suite that developers actually like to run is an enormous value, maybe especially for new team members. It gives you confidence when making changes and adding features.

A basic purpose of TDD is to make it obvious when code is hard to test, so that you're always encouraged to write units that can be unit tested without difficulty. That's a skill that takes some practice and learning, and you need to pay real attention to it. When your team understands how to do it, that's when the test suites start to make real sense, and it becomes pretty much a pleasure to write the tests.

I don't know about being a consultant but I'd like to say that comprehensive testing is a necessary standard part of professional programming just like serious manufacturers verify the quality of components. It can also reduce the stress and anxiety of developers which leads to a better work environment and better quality.

As a coder in a team with half legacy and half well tested code, I know it was a delight to work on the modules developed according to good TDD practice.

Well, I'm not entirely sold on TDD just yet, but after applying it for a few years now, the benefits seem to be:

- Requires you to think about structure before you write the actual code. Code that is unit testable is usually better code. (but not necessarily)

- Requires you to think about the scenarios that you will support beforehand.

- Ensures that every file is unit tested. Without TDD you can have untested files. Why unit tests are great is another topic entirely.

- Ensures that tests cannot return false positives. TDD requires you to write and run your tests before any real code is written, so all tests should be red in the beginning. If you write your tests afterwards, your test could be green when in fact the code is incorrect.

What I don't like about TDD is that it pushes your code towards very easy to test code, which is not always better code. I'm more inclined nowadays to just start with the actual code, refactor iteratively until I'm satisfied, and then write the tests. This reduces the total amount of work, because otherwise you also need to refactor your tests every iteration, which only gets written at the end with my method. The downsides are that unit tests can be forgotten, or that you can write false positive tests. In my experience though, this rarely happens.

The most important part - imho - is to have meaningful unit tests.

Truth be told, I value solid integration tests more than unit tests, because they actually test the input/output of your system, which at the end of the day is the most important thing. Unfortunately integration tests tend to be more fragile and require more maintenance. On the other hand, they are more resistant against refactoring, while unit tests essentially have to be rewritten when any kind of refactoring happens.

Nowadays, I write both unit tests and integration tests, which is expensive to write and maintain, but in return they provide you with peace of mind and confidence, which is priceless imho.

Hmm, having a test do anything more than one thing sounds like a functional or integration test.

The deal with TDD is you write twice as much code and you have less than half the bugs. As the project grows, it gets harder and harder to maintain and change unless you have good tests. Most projects without good tests that I've seen grow to a certain size and then become very difficult to make progress on because people are too scared of breaking things and the releases inevitably take a very long time due to all the QA.

One great thing about TDD is that I can pick up a project I Haven't touched in a very long time or am new to and work on it and as long as all the tests run, I know I didn't break anything. Without tests, the intimate knowledge of the requirements of a system tend to get lost and the project quickly becomes unmaintainable without a guru and active development.

I'd also say that having some tests from the start is much better than not having tests. The main reason for this is that to have tests, the code has to be developed with testing in mind. The second thing is that if you have a build system and a framework for writing tests, you can easily add new tests for tricky bugs or corner cases.

If you really want to go fast and loose, you should at least have a happy path integration test, a test for all the dao methods and at least a happy path test for the controllers. Any parts of the code that are tricky or algorithmically clever should also have tests. As your QA team runs into regressions, write tests for those regressions. This is a way I've found to amortize the test writing somewhat. It's important though that the test running is integrated into the build at these levels and is run before every release.