3 ms·

I like the take that people who dislike TDD just haven't seen good TDD. I also like the take that people who exalt TDD are bad programmers. Both are hypothetica

by zzbzq 5y ago

I like the take that people who dislike TDD just haven't seen good TDD. I also like the take that people who exalt TDD are bad programmers. Both are hypothetically possible.

philwelch 5y ago
What about people with nuanced takes on TDD? A lot of what turns me off about TDD is the dogmatism. If I'm coding a bug fix, I will often start by writing a unit test that reproduces the root cause of the bug because I don't want a regression, and I want to be sure that my unit test actually catches the bug before I fix it. If I'm writing a pure function and I want unit test coverage on it, I might as well write the unit tests first. But it's not necessarily useful to write all of your unit tests first.
- postalrat 5y ago
  What do you do when you write the test, "fix" the bug, only to find out the bug you saw is just a small example of a larger bug.
  - philwelch 5y ago
    Depends. Maybe I throw everything away, write a new unit test for the true root cause, and start over from there. I’m comfortable taking very long journeys to reach very small code changes if that’s the best solution.
    - theK 5y ago
      Correct, often a root cause fix turns out to introduce much less complexity than a symptom fix.
- taylodl 5y ago
  What you're doing is similar to what I call Maintenance-Driven Development (https://taylodl.wordpress.com/2012/07/21/maintenance-driven-development/ https://taylodl.wordpress.com/2012/07/21/maintenance-driven-...). Put your testing effort in things that are likely to fail and don't insist on 100% code coverage, not even close. For example, I hear people complain all the time about how stupid it is to test getters/setters. So don't write tests for them (even better, don't implement them - but that's another story!) They're not likely to fail. Maybe if a code's cycolomatic complexity score exceeds a certain value then test it (consider refactoring to reduce the complexity too!) In my decades of software development experience I can tell you most developers have a good "feel" for what needs to be tested and what doesn't. Listen to them - they're usually right. If they're not then you'll catch it on the break-fix.

by zzbzq 5y ago

I like the take that people who dislike TDD just haven't seen good TDD. I also like the take that people who exalt TDD are bad programmers. Both are hypothetically possible.

philwelch 5y ago

What about people with nuanced takes on TDD? A lot of what turns me off about TDD is the dogmatism. If I'm coding a bug fix, I will often start by writing a unit test that reproduces the root cause of the bug because I don't want a regression, and I want to be sure that my unit test actually catches the bug before I fix it. If I'm writing a pure function and I want unit test coverage on it, I might as well write the unit tests first. But it's not necessarily useful to write all of your unit tests first.

postalrat 5y ago
What do you do when you write the test, "fix" the bug, only to find out the bug you saw is just a small example of a larger bug.
- philwelch 5y ago
  Depends. Maybe I throw everything away, write a new unit test for the true root cause, and start over from there. I’m comfortable taking very long journeys to reach very small code changes if that’s the best solution.
  - theK 5y ago
    Correct, often a root cause fix turns out to introduce much less complexity than a symptom fix.
taylodl 5y ago
What you're doing is similar to what I call Maintenance-Driven Development (https://taylodl.wordpress.com/2012/07/21/maintenance-driven-development/ https://taylodl.wordpress.com/2012/07/21/maintenance-driven-...). Put your testing effort in things that are likely to fail and don't insist on 100% code coverage, not even close. For example, I hear people complain all the time about how stupid it is to test getters/setters. So don't write tests for them (even better, don't implement them - but that's another story!) They're not likely to fail. Maybe if a code's cycolomatic complexity score exceeds a certain value then test it (consider refactoring to reduce the complexity too!) In my decades of software development experience I can tell you most developers have a good "feel" for what needs to be tested and what doesn't. Listen to them - they're usually right. If they're not then you'll catch it on the break-fix.