There are new Ada projects, not just legacy updates. Many UK and US civil and defence projects use Ada, and various companies like Rapita Systems use Ada for their desktop applications. I wish more companies wounde would use it, but many play the "can't recruit" card, which is just a poor excuse.
Of course you cannot test all paths through the code, so one of the ways to have safety-critical code is to make sure that it is well tested. And that's where coverage comes in.
The way that it works for DO-178B (guidelines for airborne software) is that you do requirements-based implementation and testing. That is, you write your code AND tests from a requirements specification. Therefore, there should be NO untested code, otherwise you have either written something that's not in the requirements, or your tests are not adequately testing your requirements.
In other words, coverage is about making sure your tests are complete (not about if your software works).
This is how it's worked for a long time in aerospace, and there aren't many planes falling out the sky because of software bugs (although requirements specification issues, perhaps!)
The tetris thing does show MC/DC test coverage, which is required for DO-178B level A (the most critical software) and now in automotive software because of ISO 26262. MC/DC is basically making sure that as well as testing every statement, you also make sure that each part of a decision independently affects the branch outcome. That's been shown to catch quite a few holes in test suites.
Slashdot Mirror
There are new Ada projects, not just legacy updates. Many UK and US civil and defence projects use Ada, and various companies like Rapita Systems use Ada for their desktop applications. I wish more companies wounde would use it, but many play the "can't recruit" card, which is just a poor excuse.
Of course you cannot test all paths through the code, so one of the ways to have safety-critical code is to make sure that it is well tested. And that's where coverage comes in.
The way that it works for DO-178B (guidelines for airborne software) is that you do requirements-based implementation and testing. That is, you write your code AND tests from a requirements specification. Therefore, there should be NO untested code, otherwise you have either written something that's not in the requirements, or your tests are not adequately testing your requirements.
In other words, coverage is about making sure your tests are complete (not about if your software works).
This is how it's worked for a long time in aerospace, and there aren't many planes falling out the sky because of software bugs (although requirements specification issues, perhaps!)
The tetris thing does show MC/DC test coverage, which is required for DO-178B level A (the most critical software) and now in automotive software because of ISO 26262. MC/DC is basically making sure that as well as testing every statement, you also make sure that each part of a decision independently affects the branch outcome. That's been shown to catch quite a few holes in test suites.