Comment by hbrn
3 years ago
> Then you make a change, that change impacts 10 of those. You now need to go back and re-test, manually, those 10 thing and check they haven't broke.
Unit tests provide no guarantee that those 10 things haven't broke. They can break in a way that's not under test. Or they can be working individually, but breaking as a whole.
You still have to test those 10 things manually before merging.
Sure, sometimes unit tests will show you regression early on. Early feedback can be useful. But it will never give you confidence, it doesn't eliminate manual testing.
The important part is that you're making a change and you don't have confidence that it is safe. This is a signal of bad design. In most cases the right solution is to fix the design, not throw tests at the problem. There are exceptions of course, but even in those cases tests are not something to celebrate or be proud of.
It's like getting obese and then celebrating statin therapy. I mean it's great, but not as great as not being obese in the first place.
Agreed. That lack of guarantee generally means that it's a waste of time to even try unit testing in the first place.