How about a similar thing on the source-code control side?
A test coverage tool will mutate your codebase, e.g. changing a ‘<’ operator into a ‘<=’. It does this in order to check that one (and ideally just one) test fails as a result.
To this conventional mix, add the idea that if we find a code mutation which does not cause any tests to fail, then the mutated code is automatically committed back into our repo.
This script should be runs over production code unpredictably, several times per week.
It will teach your development team to write thorough tests, with great coverage! Or else!!!
Any tips for this kind of redundancy implementation and testing with limited memory and throughput? (Specifically embedded systems). I mean if I had an infinite amount of memory and hardware, it would be easier to add much more error handling/checking, but in an embedded system, you’re limited by both storage and speeds. Any tips for kinds of systems to improve? (not just massive server type systems basically)
