3 ms·

I want to push back on this in two ways. First, it's my understanding (as someone who usually doesn't TDD and hasn't read/thought that deeply about it in a whi

I want to push back on this in two ways. First, it's my understanding (as someone who usually doesn't TDD and hasn't read/thought that deeply about it in a while) that the core of TDD (vs other testing doctrines) was to iterate by making a failing test, then making it pass. 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, though culture does weird things to practices and definitions and I'm sure there's places that called any damned thing TDD when it had more hype. Second, I think a test (or static check) that never fails can be useful if it lets the programmer pay less attention to making sure the program is correct in that particular way (freeing up bandwidth for other important considerations), and as a communication tool demonstrating that the system does in fact work the way it does. Whether those benefits are worth it depends on a bunch of features of the particular context, including how long it takes to write/maintain the test (although if it never fails then at least you probably don't need to update it) and how long it takes to run the test.

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.
codeulike 4y ago
the core of TDD was to iterate by making a failing test, then making it pass Yes and when I first heard that 15 years ago (or whenever it was) it sounded like genius and I did it on a few projects. Its a useful crutch maybe if you're doing something very unfamiliar But as a dogma that must always be followed? And having a test for every single 'specification' and edge case? No - screw that, you end up faffing around for ages setting up mocks and testing stuff that doesnt deserve it. And you end up with a massive library of tests that get on your nerves. Also everything got completely bent out of shape for a few years because everything had to be injectable and testable. https://dhh.dk/2014/tdd-is-dead-long-live-testing.html https://dhh.dk/2014/tdd-is-dead-long-live-testing.html http://web.archive.org/web/20180215225218/https://iansommerville.com/systems-software-and-technology/giving-up-on-test-first-development/ http://web.archive.org/web/20180215225218/https://iansommerv... http://blog.cleancoder.com/uncle-bob/2016/03/19/GivingUpOnTDD.html http://blog.cleancoder.com/uncle-bob/2016/03/19/GivingUpOnTD... https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste...
- dllthomas 4y ago
  My point (in that bit) was only that your criticism was incompatible with it being the thing you labelled. I'm not pitching TDD or defending it more broadly.
  - codeulike 4y ago
    Ok. But writing the test first means it will always fail once, in my mind that doesn't count. It's like pretending.
    - dllthomas 4y ago
      > But writing the test first means it will always fail once Right, exactly. > in my mind that doesn't count. It's like pretending. ¯\_(ツ)_/¯ It demonstrates that your test is actually testing something and that your code is having an impact on that something, which in most contexts is probably not high value but is not of zero value. Pretending is when your team has agreed to TDD but you write the passing tests after the code just so no one can accuse you of not doing TDD when they weren't looking, which does seem to be what "we do TDD" sometimes turns into in practice... and even in that case, the tests may have communicative value that may be worth the weight of the test, your odds are just getting awfully low.

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.

codeulike 4y ago

the core of TDD was to iterate by making a failing test, then making it pass Yes and when I first heard that 15 years ago (or whenever it was) it sounded like genius and I did it on a few projects. Its a useful crutch maybe if you're doing something very unfamiliar But as a dogma that must always be followed? And having a test for every single 'specification' and edge case? No - screw that, you end up faffing around for ages setting up mocks and testing stuff that doesnt deserve it. And you end up with a massive library of tests that get on your nerves. Also everything got completely bent out of shape for a few years because everything had to be injectable and testable. https://dhh.dk/2014/tdd-is-dead-long-live-testing.html https://dhh.dk/2014/tdd-is-dead-long-live-testing.html http://web.archive.org/web/20180215225218/https://iansommerville.com/systems-software-and-technology/giving-up-on-test-first-development/ http://web.archive.org/web/20180215225218/https://iansommerv... http://blog.cleancoder.com/uncle-bob/2016/03/19/GivingUpOnTDD.html http://blog.cleancoder.com/uncle-bob/2016/03/19/GivingUpOnTD... https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste...

dllthomas 4y ago
My point (in that bit) was only that your criticism was incompatible with it being the thing you labelled. I'm not pitching TDD or defending it more broadly.
- codeulike 4y ago
  Ok. But writing the test first means it will always fail once, in my mind that doesn't count. It's like pretending.
  - dllthomas 4y ago
    > But writing the test first means it will always fail once Right, exactly. > in my mind that doesn't count. It's like pretending. ¯\_(ツ)_/¯ It demonstrates that your test is actually testing something and that your code is having an impact on that something, which in most contexts is probably not high value but is not of zero value. Pretending is when your team has agreed to TDD but you write the passing tests after the code just so no one can accuse you of not doing TDD when they weren't looking, which does seem to be what "we do TDD" sometimes turns into in practice... and even in that case, the tests may have communicative value that may be worth the weight of the test, your odds are just getting awfully low.