3 ms·

> If that's correct, then if you're writing tests that never fail throughout the lifetime of the project then you're not doing TDD Agreed. > [tests that never

by qudat 4y ago

> If that's correct, then if you're writing tests that never fail throughout the lifetime of the project then you're not doing TDD Agreed. > [tests that never fail can be useful] as a communication tool demonstrating that the system does in fact work the way it does. Agreed as well. That's what makes the section I wrote on testing sting for me. I read about all the benefits and see how it can be helpful as a form of documentation. I see all the upsides but at the end of the day, we still need to calculate if automated tests are really worth it. The maintenance burden on them can be huge. A couple line change and confirming it works with a manual test can take a couple of minutes, but fixing an integration test that is now failing can take the entire day or worse. It's tough, but my main goal was to challenge the dogma of "always write automated tests."

justin_oaks 4y ago
> It's tough, but my main goal was to challenge the dogma of "always write automated tests." It's perfectly fine to challenge dogma and ask people figure out whether the automated tests make sense for their use case. I think the push for automated tests came when there were so many others who grossly underestimate the benefits of automated tests and dismiss them off-hand. It's hard to see the benefits of automated testing. It's easy to see the time spent writing the tests while it's hard to see the time saved by catching bugs before they happen. It's also easier to refactor if you have tests to confirm that your refactoring didn't break something.
dllthomas 4y ago
Right, just because it has value doesn't mean it has enough value. My objection to the parent (not the article) was that it wound up dismissing certain kinds of value.