I've seen many places where unit tests are almost useless because they test the obvious stuff, so the developers think it's good enough ("we have 550 tests!"),

I've seen many places where unit tests are almost useless because they test the obvious stuff, so the developers think it's good enough ("we have 550 tests!"), but the most difficult bits are untested. If you want to get rid of them you could go with the following strategy: 1. Have code coverage (you need this regardless). Realistically you want to see branch coverage in addition to line coverage. 2. Implement an alternative test suite along the lines you suggested (integration tests) 3. Compare the coverage between the two test suites You should quickly approach the coverage of the original test suite with your integration tests. At that point, you can decide to either refine the integration tests to cover more, or write unit tests to cover the missing bits. Generally you'll know already which parts of your code really need high branch coverage. Typically, the core data structures and algorithms. It's wise to focus on unit-testing those ones. By the way I don't think you're doing anything wrong. Quite the opposite. Very few projects have comprehensive tests, so you have to find a tradeoff anyway. Many people choose the easiest path of cargo culting some unit tests for the sake of having many green bubbles in some CI panel. But if you can't have comprehensive tests, due to constraints, you might as well focus on trying to be effective, as you're trying to do. Godspeed. edit: if you don't do it already, have assertions in your code. I find them essential, and they help decouple the tests from the code under test a lot.