I agree. Everyone should consider the costs and benefits of testing to arrive at a system that works for them.
Early on in a system design, I prefer going overboard with integration tests.
The architecture is hard to predict early on, so I don't want to get paralyzed on figuring it out. Just get the tests passing without overthinking.
Once I find a better way to do things, I can rip apart and restructure the internals with the safety net of end to end tests.
I rarely write unit tests at this stage because the effort of writing and rewriting them adds friction to getting the software working and restructuring the code.
If every time I redraw a boundary, I need to rewrite a bunch of unit tests, I'll be less likely to improve the code quality.
Early on in a system design, I prefer going overboard with integration tests.
The architecture is hard to predict early on, so I don't want to get paralyzed on figuring it out. Just get the tests passing without overthinking.
Once I find a better way to do things, I can rip apart and restructure the internals with the safety net of end to end tests.
I rarely write unit tests at this stage because the effort of writing and rewriting them adds friction to getting the software working and restructuring the code.
If every time I redraw a boundary, I need to rewrite a bunch of unit tests, I'll be less likely to improve the code quality.