Repository navigation
The report-completeness "parity test" could not detect the drift it guarded - #1564
Merged
Merged
Conversation
…uarded Follow-up to #1531. @bhelm corrected the Swift side's false claim that the two completeness guards are kept aligned by a parity test. The same falsehood was mirrored on the Android side, which that PR did not touch, so the two files were left openly contradicting each other. ReportCompleteness.kt claimed its token map was "byte-identical to the Swift twin", and named a Swift type -- ReportCompleteness -- that does not exist; Swift's is CaptureCompleteness. Measured against the ten tokens the test pins: four match Swift exactly, three differ only by a trailing fragment, and three have no counterpart in the Swift map at all -- import ("import parser=" vs "import stage="), steps ("stepsEst " vs "stepsRaw") and battery ("battery series=" vs "bank soc="). That divergence is not a bug to fix. Each side must key on the tokens ITS OWN emitters write, and the two platforms word several of those lines differently, so aligning the maps would break the guard on whichever platform lost. The header now says so explicitly, with the three cases named, so nobody "corrects" them into alignment later. The test was the worse half. ReportCompletenessParityTest asserted "Byte-identical to the Swift ReportCompleteness.killerTokens" and then pinned literals held in the test file itself. It never read the Swift side, so it could not fail when the platforms drifted -- and it stayed green throughout the divergence above. A test that names a guarantee it cannot check is worse than no test, because it invites a reader to stop looking. Renamed to ReportCompletenessContractTest and its doc rewritten to say what it actually guarantees, which is still worth having: Android's own map, section ordering and present/MISSING wording cannot change by accident. The cross- platform contract that DOES matter -- the section a maintainer reads being identically shaped -- is called out as the real one. Comments and the class rename only; no assertion, token or logic changed. All 17 tests still pass under the new name, Android 4241 tests / 0 failures matching main, doc lint clean.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Follow-up to #1531. @bhelm corrected the Swift side's false claim that the two completeness guards are kept aligned by a parity test. The same falsehood was mirrored on the Android side, which that PR did not touch — so the two files were left openly contradicting each other.
What was wrong
ReportCompleteness.ktclaimed its token map was "byte-identical to the Swift twin", and named a Swift type —ReportCompleteness— that does not exist. Swift's isCaptureCompleteness.Measured against the ten tokens the test pins:
import parser=vsimport stage=,stepsEstvsstepsRaw,battery series=vsbank soc=The divergence is not a bug
Each side must key on the tokens its own emitters write, and the two platforms word several of those lines differently. Aligning the maps would break the guard on whichever platform lost. The header now says so explicitly, with the three cases named, so nobody "corrects" them into alignment later.
The test was the worse half
ReportCompletenessParityTestasserted "Byte-identical to the Swift ReportCompleteness.killerTokens" — and then pinned literals held in the test file itself. It never read the Swift side, so it could not fail when the platforms drifted, and it stayed green throughout the divergence above.A test that names a guarantee it cannot check is worse than no test, because it invites a reader to stop looking. That is exactly what happened here: the claim survived long enough for three tokens to lose their counterparts entirely.
Renamed to
ReportCompletenessContractTest, with its doc rewritten to state what it actually guarantees — which is still worth having: Android's own map, section ordering and present/MISSING wording cannot change by accident. The cross-platform contract that does matter (the section a maintainer reads being identically shaped) is now called out as the real one.Verification
class ReportCompletenessParityTest→class ReportCompletenessContractTest.app-builddoes not apply.