in my experience the hard parts in software are remote interactions, i.e. behavior that localized unit testing has a hard time to capture, and concurrency. so

in my experience the hard parts in software are remote interactions, i.e. behavior that localized unit testing has a hard time to capture, and concurrency. so the valuable tests, those which actually find issues, are the tests in near production environments under near production load. now I'm not sure if you describe just superficial testing, at all levels, including the "integration" and "selenium-ish" level? did you ever measure code coverage across all tests? my thinking is rather you only need to consider unit tests for those paths that are not touched by your integration and system tests. my aha moment was when SQLite, famous for their efforts in full MCDC coverage, found uncomfortably many bugs through fuzzing. the SQLite team realized they didn't add corner case checks where it was hard to create a test case "because nobody provides suchandsuch input anyhow". so my take would be to measure the coverage in the testing of your organization, to look at what you find and to then decide as a team where you have business risk level "undercoverage".