4 ms·

You say that like its a bad thing. Sure dogmatic TDD can lead to issues, but going through a period of dogmatic TDD has, for me, resulted in becoming a far bett

You say that like its a bad thing. Sure dogmatic TDD can lead to issues, but going through a period of dogmatic TDD has, for me, resulted in becoming a far better programmer. And as time goes on I find myself drifting further back towards the dogmatic side of TDD as I know the difference how it feels working on tested portions of our code vs the untested portions of our code.

JohnHaugeland 5y ago
> You say that like its a bad thing. That's because it is
astrange 5y ago
It is kind of a bad thing. Recently at work there was a quality program introduced by some training guy, but by quality they seemed to mean write more tests and do TDD, and our junior engineers read that as write a ton of unit tests (the only kind they'd heard of.) I pointed out the 10 year old Norvig vs Ron Jeffries fight[1] which demonstrates that TDD is useless when you don't already know what you're writing, but they just looked confused. The other problem here is that unit tests never break (since you've mocked everything that can break) and therefore aren't worth running; it might be more productive to write them for TDD and then just not commit them. [1] https://news.ycombinator.com/item?id=3033446 https://news.ycombinator.com/item?id=3033446
- blacktriangle 5y ago
  I agree with you, which is why I think the GPs post that TDD is not a dogma but another tool in your toolbox makes sense. Just like the larger development community when faced with new tools, individual developers go through the pattern of adoption where they start using a technique for everything (the honeymoon phase) and then through that phase they learn when the tool is appropriate and when the tool I not. As posters in your linked thread point out, the irony is that Norvig would have probably been better off using TDD since he knew the general shape of his solution already where Jeffries likely should have been writing several spikes to explore the solution space rather than using TDD since he was unfamiliar with the problem and did not yet have a good solution.
- bluGill 5y ago
  Unit tests do break once in a while. 80% will never break once written and should be thrown away, but that other 20% will unexpectedly break in the future alerting you to a problem that otherwise you wouldn't find until much latter in the release cycle. I don't know have any way to know which tests are in the 20% and which the 80% to throw away, which is why I keep them all. Of course the 80%/20% figures are estimates. The longer your code is maintained the more likely it is some tests will break.
  - karmelapple 5y ago
    Can confirm. Recently had simple unit tests that almost seemed, on first glance, to indicate, “huh, why are these tests here?” Upgraded to NodeJS 12 where some details about sorting arrays were changed, and we got 2 failing tests. Before that, I would have bet money that those tests would never fail.
    - astrange 5y ago
      Was that the point of the tests, or just a coincidence? Now that they've failed once they've become regression tests (one of the most useful kind of test), but if you set out wanting to test the platform under you I think you'd want to do a lot more work than that.
      - karmelapple 5y ago
        I might be missing the question - are you asking if the point of the tests was to check that it would work when we upgrade a version of NodeJS? The point of our tests was to document a requirement we had - in this case, how some data sorted. That test was able to eliminate questions of the "how" - whether the sort was done in our database layer or our NodeJS layer - and let us focus on the important outcome: are the things sorted in the right way? We didn't write them because of the NodeJS 12 upgrade. We wrote them 5 years ago. We added them because writing them captured a requirement. And when an unexpected reason caused that functionality to break, we avoided shipping a bug in our software. Regression tests are certainly useful, and every time we ship a bug, we attempt to write an automated regression test. But I wouldn't argue they're one of the most useful - equally useful is any test that captures a requirement.
- solipsism 5y ago
  The other problem here is that unit tests never break (since you've mocked everything that can break) and therefore aren't worth running; it might be more productive to write them for TDD and then just not commit them. That's fine for code that never changes, or that has no logic in it. As soon as you want to change some code, you'll want a portion of the tests to require modification and a portion to stay passing.
- 8note 5y ago
  Unit tests that don't break are documentation, both about your code, and what you expect dependencies to do. Gives you something to compare against if the dependency changes its behaviour

JohnHaugeland 5y ago

> You say that like its a bad thing. That's because it is

astrange 5y ago

It is kind of a bad thing. Recently at work there was a quality program introduced by some training guy, but by quality they seemed to mean write more tests and do TDD, and our junior engineers read that as write a ton of unit tests (the only kind they'd heard of.) I pointed out the 10 year old Norvig vs Ron Jeffries fight[1] which demonstrates that TDD is useless when you don't already know what you're writing, but they just looked confused. The other problem here is that unit tests never break (since you've mocked everything that can break) and therefore aren't worth running; it might be more productive to write them for TDD and then just not commit them. [1] https://news.ycombinator.com/item?id=3033446 https://news.ycombinator.com/item?id=3033446

blacktriangle 5y ago
I agree with you, which is why I think the GPs post that TDD is not a dogma but another tool in your toolbox makes sense. Just like the larger development community when faced with new tools, individual developers go through the pattern of adoption where they start using a technique for everything (the honeymoon phase) and then through that phase they learn when the tool is appropriate and when the tool I not. As posters in your linked thread point out, the irony is that Norvig would have probably been better off using TDD since he knew the general shape of his solution already where Jeffries likely should have been writing several spikes to explore the solution space rather than using TDD since he was unfamiliar with the problem and did not yet have a good solution.
bluGill 5y ago
Unit tests do break once in a while. 80% will never break once written and should be thrown away, but that other 20% will unexpectedly break in the future alerting you to a problem that otherwise you wouldn't find until much latter in the release cycle. I don't know have any way to know which tests are in the 20% and which the 80% to throw away, which is why I keep them all. Of course the 80%/20% figures are estimates. The longer your code is maintained the more likely it is some tests will break.
- karmelapple 5y ago
  Can confirm. Recently had simple unit tests that almost seemed, on first glance, to indicate, “huh, why are these tests here?” Upgraded to NodeJS 12 where some details about sorting arrays were changed, and we got 2 failing tests. Before that, I would have bet money that those tests would never fail.
  - astrange 5y ago
    Was that the point of the tests, or just a coincidence? Now that they've failed once they've become regression tests (one of the most useful kind of test), but if you set out wanting to test the platform under you I think you'd want to do a lot more work than that.
    - karmelapple 5y ago
      I might be missing the question - are you asking if the point of the tests was to check that it would work when we upgrade a version of NodeJS? The point of our tests was to document a requirement we had - in this case, how some data sorted. That test was able to eliminate questions of the "how" - whether the sort was done in our database layer or our NodeJS layer - and let us focus on the important outcome: are the things sorted in the right way? We didn't write them because of the NodeJS 12 upgrade. We wrote them 5 years ago. We added them because writing them captured a requirement. And when an unexpected reason caused that functionality to break, we avoided shipping a bug in our software. Regression tests are certainly useful, and every time we ship a bug, we attempt to write an automated regression test. But I wouldn't argue they're one of the most useful - equally useful is any test that captures a requirement.
solipsism 5y ago
The other problem here is that unit tests never break (since you've mocked everything that can break) and therefore aren't worth running; it might be more productive to write them for TDD and then just not commit them. That's fine for code that never changes, or that has no logic in it. As soon as you want to change some code, you'll want a portion of the tests to require modification and a portion to stay passing.
8note 5y ago
Unit tests that don't break are documentation, both about your code, and what you expect dependencies to do. Gives you something to compare against if the dependency changes its behaviour