5 ms·

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

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.

Aeolun 6y ago
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.
- dnautics 6y ago
  Refactoring is quadratically more difficult if you don't have tests.
  - mbeex 6y ago
    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.
    - vendiddy 6y ago
      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.
    - bvirb 6y ago
      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).
- rebeccaskinner 6y ago
  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.
  - Aeolun 6y ago
    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.
- captrb 6y ago
  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.
brundolf 6y ago
> 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.
- dnautics 6y ago
  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.
  - john-shaffer 6y ago
    > 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.
eecks 6y ago
First time I have every heard of "detroit-style" TDD (and from looking it up "London-style"). Why were they given these names?
- greenyoda 6y ago
  This article explains it: https://medium.com/dev-genius/detroit-and-london-schools-of-test-driven-development-3d2f8dca71e5 https://medium.com/dev-genius/detroit-and-london-schools-of-...
vendiddy 6y ago
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.
pydry 6y ago
>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.

Aeolun 6y ago

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.

dnautics 6y ago
Refactoring is quadratically more difficult if you don't have tests.
- mbeex 6y ago
  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.
  - vendiddy 6y ago
    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.
  - bvirb 6y ago
    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).
rebeccaskinner 6y ago
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.
- Aeolun 6y ago
  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.
captrb 6y ago
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.

brundolf 6y ago

> 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.

dnautics 6y ago
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.
- john-shaffer 6y ago
  > 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.

eecks 6y ago

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

greenyoda 6y ago
This article explains it: https://medium.com/dev-genius/detroit-and-london-schools-of-test-driven-development-3d2f8dca71e5 https://medium.com/dev-genius/detroit-and-london-schools-of-...

vendiddy 6y ago

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.

pydry 6y ago

>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.