Hacker News Reader

Comment by dnautics | Hacker News Reader

Here's what i have to say about TDD (I do not practice TDD on a day-to-day basis).

Even if you don't use it, you should know what it is. If you choose to use it religiously, that's probably a bad choice, but if you don't do it ever, you are missing out on a huge tool. In general, if I see an insurmountably complex challenge ahead of myself, sometimes TDD (especially detroit-style TDD) is a tool to refocus my attention and implement the minimal implementation and move past goals.

Also, doing test-heavy development (which TDD gives you for free) gives you insight into how that break/fix loop can supercharge your productivity by giving you those dopamine rushes as a reward for your effort.

View on HN

> how that break/fix loop can supercharge your productivity by giving you those dopamine rushes as a reward for your effort

It's interesting to hear someone come out and say that there's a link between how "fun" a coding workflow is and how productive it is. I think most of us know it, but nobody ever talks about it. I wonder if it could be harnessed better.

It's kind of like a drug. I don't play any more video games - coding is my video game. I'm convinced that strategic use of those green dots is why I don't burn out much anymore, I just pushed through a month-ish emotional slog that in the past would have triggered full-on burnout but still wrote lots of code for work, my personal projects, and produced the deliverables for my job only a day-ish later than I said I would.

> It's kind of like a drug. I don't play any more video games - coding is my video game.

I feel the same way. I just make sure I take one full day off a week and play games or read. I can still get burned out, but it's generally short-lived.

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.

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.

>can supercharge your productivity by giving you those dopamine rushes

These dopamine rushes unfortunately have a nasty side effect of turning people into TDD zealots.

TDD works great where it works, but it often has a nasty side effect of spewing out tests which don't tell you anything useful and demand near constant maintenance to keep the build pipelines alive.

The zealots seeking a dopamine high will tolerate this in pursuit of their high and will churn out unit tests. The zero-benefit-high-cost unit test maintenance eats into the entire team's testing budget without producing a commensurate return on investment.

Agree. I also found that learning TDD rewired my brain to think top down.

So in the many cases I don't do TDD, I imagine what the top level API ought to be before I dive in and start coding.

First time I have every heard of "detroit-style" TDD (and from looking it up "London-style"). Why were they given these names?

This article explains it: https://medium.com/dev-genius/detroit-and-london-schools-of-...

Reply on news.ycombinator.com