You're not really addressing what I've said. Sure, formal verification and ensuring code coverage is a higher standard of verification than unit testing. But th

You're not really addressing what I've said. Sure, formal verification and ensuring code coverage is a higher standard of verification than unit testing. But that doesn't mean your unit testing provides literally the same probability of finding the bug as completely random test inputs. If you're writing decent tests your chance of finding that bug isn't 1%, it's way higher. In fact I think your entire appraoch to this is wrong. >Given that most people don’t know what MC/DC or the category partition method are, I doubt that there are many actually effective test suites out there. Given that most people aren't writing software to go into safety critical applications, it doesn't make sense for them to be designing their test suites to that standard. What I'm saying is that this method of testing boils down to hoping that the master is correct (which it probably isn't) and then trusting someone else's tool to provide coverage for you. This is worse than writing unit tests because the tool you've handed responsibility to for coverage doesn't know anything about your device under test and therefore can't direct it's tests to maximize the likelihood of finding errors. At the very least writing a simple model to test against would be more effective because you'd expose bugs in the detail-orientated implementation.