Notemapper completeness: equivalents around skipped flat-keys, and ♯-support #90
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have recently been reading architecture articles on not striving for 100% code coverage.
I found this very enlightening, as it's the opposite to what I've been doing so far.
The articles posit that 100% coverage as a blind goal leads to very brittle tests, needless busywork when refactoring codes (due to overfitted test-cases), and in general is a dogma that should not be blindly followed.
Instead, the articles advise to use coverage-gaps to guide deeper analysis of the productive code, looking for holes that bugs could theoretically hide in.
I revisited my (spotty)
NoteMapperTest
while attempting to keep this mindset.At the same time, reading about fuzz-testing inspired me to do an unbiased "all possible notes" test, which indeed uncovered gaps.
Ironically, I did end up with 100% line coverage 😝
(Though my branch-coverage is stuck at 75%, and I can't seem to figure out why)
P.S. The articles, in case others feel inspired.
As for release-cutting: since this has zero user-visible benefit, I wouldn't mind if this is not included in the release for the Brother-John-Song (#88, #89), so please don't consider this urgent.