A useful gate is to run the new regression test against the unpatched revision first. It should fail for the reported behavior, then pass with the fix. Otherwise it's surprisingly easy to write a test that only confirms the new implementation's assumptions.
For a parser fix, I'd also test the boundaries that the parser feeds into: empty/truncated/extra-length input, max and max+1, signedness, and invalid values that still have a valid checksum. Keep a known-good compatibility vector alongside those rejection cases.
I used that sequence on a small public reference module today: its original tests were green, but the added boundary cases were not. A green test suite is only as reassuring as the behaviors it actually exercises.
A useful gate is to run the new regression test against the unpatched revision first. It should fail for the reported behavior, then pass with the fix. Otherwise it's surprisingly easy to write a test that only confirms the new implementation's assumptions.
For a parser fix, I'd also test the boundaries that the parser feeds into: empty/truncated/extra-length input, max and max+1, signedness, and invalid values that still have a valid checksum. Keep a known-good compatibility vector alongside those rejection cases.
I used that sequence on a small public reference module today: its original tests were green, but the added boundary cases were not. A green test suite is only as reassuring as the behaviors it actually exercises.