You need automated tests for regression testing. As you do software changes, it's a very wise idea to run the whole test suite on the software. You want to do it as early and as often as possible, to make sure that some change you made in part "A" in the software to enable an improvement in part "B" didn't break part "G" or "P" or "Z".
They can also, /to some extent/, be used to ensure that as the implementation progresses the detailed "structural" implementation corresponds to the high-level "behavioural" specification. In other words they can aid verifying the implementation matches the validated specification.
Yes, agreed. However this sort of thing doesn't necessarily need to be automated -- in theory it just needs to be done once.
The reason you want to automate is because relentless testing is a Really Good Thing (even if it's neither necessary nor sufficient to good quality), particularly when it comes to catching the kind of problem I mention above.
Unless you prepare to make modifications and you want to automate the testing for the sake of simplicity and of systematicity.
If the tests are not automated you or somebody else will take the short path and will only test the barely minimum.
Yes I agree. That is a given. I assume a programmer that is skilled in the language, including knowing undefined behavior and how to avoid it.
That would be why I said "in theory".
That would be why I wrote the statement below:
You were proposing turning off compiler optimizations in order to make the program do predictable things when it encountered undefined behavior. That's different from avoiding undefined behavior. Avoiding undefined behavior in complex C programs seems to be very difficult for human programmers including experts; thus the interest among some of us in better-defined languages such as Ada.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required