This is one of the major sources of bugs in my experience. People write unit tests that are perfect and pass, but only pass because you give it exactly the righ

This is one of the major sources of bugs in my experience. People write unit tests that are perfect and pass, but only pass because you give it exactly the right input to make it pass in the first place. Then when running the actual app, the data is not exactly like on the unit test and you have bugs. To cover those scenarios, we use integration/acceptance tests. So I always come back to the same question: then why should I even bother with unit tests? Especially the unit tests that people normalized (test per class/public method). You end up with unit tests that are extremely coupled to the implementation, and without proper integration tests, you can't guarantee it will all work anyways. It only works on a bubble. I believe tests should be much more about the broader behaviors than the implementation details, but TDD and evangelists of today will have you writing tests for every small class you create. I personally still use unit tests from time to time when there are a ton of edge cases on a single behavior that I want to test, but that's the exception not the rule. By avoiding unit tests, or to put it differently making the units tested larger, you get more space to refactor, less coupling between tests and implementation as well as more meaningful tests. Somewhere along the way we lost the meaning of "unit" and it became "class/methods", when it was originally supposed to be more at a module level.