3 ms·
agree w/ the classifications of greefield, brownfield & maintenance i would also add regressions as a place where TDD is excellent: reproduce the regression wi
by recursivedoubts 2y ago
agree w/ the classifications of greefield, brownfield & maintenance
i would also add regressions as a place where TDD is excellent: reproduce the regression with a failing test, then fix it
it is exasperating that TDD advocates will often not admit that there are any tradeoffs or contexts in which it is more or less appropriate, and I think it does a lot of damage to the reputation of the technique (which can be effective in some contexts) as consultants snake-oil
- vitus 2y ago> reproduce the regression with a failing test, then fix it Not just regressions, but bugs in general. If you can reproduce your bug in a test, then verify that your fix causes your test to pass, that's a great way to build confidence before trying out your code in production. And in fact, this is mentioned in the article as part of maintenance: > Writing a test first to prove out a bug before you fix it is pretty neat.
- herpdyderp 2y agoIt's also a great way to codify "hey we found this edge case once" and make sure it doesn't happen again.
- litenboll 2y agoThat's the only type of test I know for sure has value, which makes them easy to write. At work I feel a certain pressure to test more or less everything, but personally I much prefer a "common sense"-approach: Writing tests is motivated by either bugs found (including any issues you run into during the initial implementation) and/or complex operations that are easy to get wrong and could need the extra documentation that tests provide. I dispise aiming for 100% code completion, so much of that is just idealism and wasteful.