Hacker News Reader

Comment by Aeolun | Hacker News Reader

I think the best part of doing test driven development (or similar) is that making your code easily testable generally also makes it architecturally sound.

View on HN

I've heard this argument a lot, but some of the worst codebases I've ever worked with have been heavily test-driven code. The need to have a failing test for every line of code combined with a tunnel-vision devotion to YAGNI and working in small pieced ended up creating these elaborate layers of functions that did no useful work except glue test cases together. Straighforward refactoring that might have taken an hour or two ended up taking days because every few keystrokes had to be validated by intermediate tests that would be invalidated by the next incremental phase of the refactor.

Granted that particular team was an extremely low-skill team in general, and I've used TDD now and again successfully when it fit my needs, but that experience was a pretty strong counter-example to the strong claims made by TDD proponents about how it improves the quality of code.

I suppose it’s possible to destroy everything. But I’d still prefer the over-tested code to the code that isn’t tested at all.

Yes. I like that TDD - when I judiciously employ it - makes me think about my interfaces. It’s like a pre-PR that forces me to question whether the intent is clear. It makes me reference guidance from DDD and single-responsibility-ish idioms.

Refactoring is quadratically more difficult if you don't have tests.

Not this simple. Refactoring might mean invariance, but the more comprehensive your tests are, the more they also test the moving parts. That means, they have to be changed too. Many people forget the maintenance costs (and this has a much broader meaning than the refactoring example). Tests themselves have to be considered as a software (or more general) artifact with a cost.

I agree coupling your tests to your code will cause resistance to refactoring as the tests have to change w/ the code. Lack of coverage also causes the resistance due to breaking things. I think you have to find a balance.

We write almost entirely integration tests (and lots of them) and we rarely need to maintain tests since they're only tied to the UI. Most refactors happen w/ no test changes at all. Occasionally a UI change causes a big find/replace across lots of tests.

The tests are also probably less comprehensive than a suite of finer grained tests would be. Most tests tend to cover happy path and few edge cases.

When we started there were zero tests and refactoring was too risky so the early code decisions largely had to follow the architecture that was already present (which wasn't always what we wanted). As we filled out the tests for existing behavior we could refactor more.

I think the mostly-integration-testing approach led us to a pretty good balance by only coupling the test to the UI (with its own cons of course).

For this reason, I prefer going heavy with integration tests early in in a design.

This way I'm not rewriting tests every time I need to rip apart and restructure the internals but I still have the safety net of refactoring without breaking the external contract.

Reply on news.ycombinator.com