I’m currently taking the Software Testing class on Udacity. The instructor spent a couple of videos discussing the pros and cons of leaving software assertions turned on in your production systems. Here is my interpretation:
When to disable software assertions
2 thoughts on “When to disable software assertions”
Comments are closed.
Maybe I should have had a look at the class before posting, but due to certain time constraints I don’t have this luxury.
The above decision seems to be only hardware related, which would sound too restrictive. I use assertions mainly like guardians, for software quality and to test software corner case that should never happen.
These corner cases are generally hit by the software being used in a different way than originally designed for. So when the execution path changes so dramatically, I want to see an assertion fail, no matter what the reason is – and there are many (out of test boundary, different environment, software evolution, …).
Therefore I would always keep assertions in the code, catch them, and at least log them when they fail.
The only reason I’ve seen assertion removed in production code was for optimization reasons (under very high constraints of speed and/or size limits). But I would avoid that as far as possible, because it might be very difficult to reproduce a problem in debug mode. This is particularly true with a multitasking software (race conditions).
my 2 cents
I agree with what you are saying. The Udacity instructor was saying that under certain specific conditions, for example a NASA probe to Mars, the engineers made the conscious choice of disabling software assertions. The reason is that this is a single-shot program execution: even if an assertion doesn’t hold, there is a probability that the craft will make it intact to the surface of the planet. But allowing the program to abort is not an option in this case.
The same argument holds for any avionics system in general, where aborting the program will almost certainly lead to loss of life.