> For example, one reason why many corporations push really hard on having 100% unit and integration test coverage is because they have such high employee turnover that they can't rely on their engineers to maintain their own code
I'm in a similar situation as yours and have switched between big corporations and startups and now at a big co again. I used to have the opinion that unit tests are a time sink, but what changed my mind was the iteration speed unit tests gave me. Without them, to test that my code actually worked, I would either deploy to a test environment (or prod in the worst case) and if it didn't work, then that just meant a longer feedback loop. What I realized after starting to have solid unit tests was that I catch issues much earlier in the pipeline and when I finally release code to test, it works 99% of the time. The only time I've had bugs in test env was because of some implicit assumptions in my mocks in the unit test. If you think about it, that lets me iterate faster by pooling in lots of changes and releasing with confidence.
I think its natural to be biased towards testing in a real environment as opposed to unit tests, as it is more rewarding to see your code work and do what its supposed to do versus seeing it work in a stubbed out environment.
Unit tests to me are more about iteration speed and release confidence, than about corporations not trusting engineers (which is also true).
I would only write unit tests for very complex classes whose logic cannot be simplified into something readable.
Personally, I rarely introduce bugs at the unit level, almost 100% of my bugs are related to how classes/functions interact with each other - I find that bugs at the unit level are easy to track down (and often they will be caught by integration tests anyway).
I prefer integration tests because they traverse more code paths and don't need to be updated so often.
The main complaints I hear about integration tests is that they're slow and brittle but this is only the case if they rely on external microservices (or external data stores) and if test cases aren't properly isolated from each other. I use integration test cases as part of my development flow.
I'm in a similar situation as yours and have switched between big corporations and startups and now at a big co again. I used to have the opinion that unit tests are a time sink, but what changed my mind was the iteration speed unit tests gave me. Without them, to test that my code actually worked, I would either deploy to a test environment (or prod in the worst case) and if it didn't work, then that just meant a longer feedback loop. What I realized after starting to have solid unit tests was that I catch issues much earlier in the pipeline and when I finally release code to test, it works 99% of the time. The only time I've had bugs in test env was because of some implicit assumptions in my mocks in the unit test. If you think about it, that lets me iterate faster by pooling in lots of changes and releasing with confidence.
I think its natural to be biased towards testing in a real environment as opposed to unit tests, as it is more rewarding to see your code work and do what its supposed to do versus seeing it work in a stubbed out environment.
Unit tests to me are more about iteration speed and release confidence, than about corporations not trusting engineers (which is also true).