The vast majority of code in VStar's GUI package is not covered by unit tests.
This artificially skews coverage for non-GUI code, of which there is a signifiant amount and makes determining what additional non-GUI code to focus on, difficult.
Moreover, the lack of GUI code coverage is a worry to me and contributes to the lack of coverage more than I expected.
What to do about this? Some possibilities:
- Exclude ui (and possibly ui.*) package code from the coverage report, at least if below some threshold or even just zero.
- Add a category of tests for GUI code. What Java frameworks make sense for this?
- Anything else?
VStar represents a long-standing, rich code base. My strong sense is that there ought to be creative ways to improve the verification of the code base, even before we get to formal verification.
The vast majority of code in VStar's GUI package is not covered by unit tests.
This artificially skews coverage for non-GUI code, of which there is a signifiant amount and makes determining what additional non-GUI code to focus on, difficult.
Moreover, the lack of GUI code coverage is a worry to me and contributes to the lack of coverage more than I expected.
What to do about this? Some possibilities:
VStar represents a long-standing, rich code base. My strong sense is that there ought to be creative ways to improve the verification of the code base, even before we get to formal verification.