3 ms·

>If this test fails, it’s hard to see what exactly is broken. Breaking existing tests is rare. I don't mind some detective work when it happens. You start with

>If this test fails, it’s hard to see what exactly is broken. Breaking existing tests is rare. I don't mind some detective work when it happens. You start with a pretty strong lead, anyway: whatever you touched since the last time the test passed. In my workflow this is unlikely to be more than five minutes ago. Half the time I know what I broke without even looking. I can see how specificity in test results would be important if you're running tests very infrequently and accumulating a lot of change between runs. But in that case I would probably invest in faster feedback before I'd invest in specificity. Huge, wordy test suites are expensive and can ossify bad design much more strongly than they preserve correct behavior.

ThePadawan 6y ago
> Breaking existing tests is rare. I don't mind some detective work when it happens. You start with a pretty strong lead, anyway: whatever you touched since the last time the test passed. You describe the exact situation where the advice is not helpful at all. Now imagine a large, very tightly interwoven codebase where in fact, making changes to a section of code breaks tests on the complete other side of the application. If you don't follow that advice, you are immediately blocked, and pretty much at the mercy of someone else fixing their test (probably to be less needlessly specific or less assertive after changing requirements). If they structured their test in a way that makes it clear why it should fail, you have the chance to investigate yourself how this contradicts with your changes.
- rightbyte 6y ago
  That's a organization problem (bunkers, are they called silos?) not a coding problem. I wish people would specify their coding advice with "advice for big projects with square process", "advice for dysfunctional planning", "advice for small team" etc.
- throwaway_pdp09 6y ago
  > very tightly interwoven Perhaps this is your problem.
  - ThePadawan 6y ago
    Of course. But you can't fix that by testing, only improve how to cope :)
  - pydry 6y ago
    It's a problem tightly coupled unit testing makes worse.
adrianN 6y ago
If breaking existing tests is rare, you don't have enough tests or a superhuman ability to organize your code.

ThePadawan 6y ago

> Breaking existing tests is rare. I don't mind some detective work when it happens. You start with a pretty strong lead, anyway: whatever you touched since the last time the test passed. You describe the exact situation where the advice is not helpful at all. Now imagine a large, very tightly interwoven codebase where in fact, making changes to a section of code breaks tests on the complete other side of the application. If you don't follow that advice, you are immediately blocked, and pretty much at the mercy of someone else fixing their test (probably to be less needlessly specific or less assertive after changing requirements). If they structured their test in a way that makes it clear why it should fail, you have the chance to investigate yourself how this contradicts with your changes.

rightbyte 6y ago
That's a organization problem (bunkers, are they called silos?) not a coding problem. I wish people would specify their coding advice with "advice for big projects with square process", "advice for dysfunctional planning", "advice for small team" etc.
throwaway_pdp09 6y ago
> very tightly interwoven Perhaps this is your problem.
- ThePadawan 6y ago
  Of course. But you can't fix that by testing, only improve how to cope :)
- pydry 6y ago
  It's a problem tightly coupled unit testing makes worse.

adrianN 6y ago

If breaking existing tests is rare, you don't have enough tests or a superhuman ability to organize your code.