test(liveness): add screenshot coverage for overlay chrome - #335
Draft
mattcreaser wants to merge 1 commit into
Draft
mattcreaser wants to merge 1 commit into
mattcreaser wants to merge 1 commit into
Conversation
The existing @previews render each element on the preview's own surface, so they cannot show how the chrome looks against the backdrop it is actually drawn over. These tests render each element over its real backdrop — the camera feed, the white FaceGuide scrim, and the themed start view backdrop — in both default color schemes. Extracts FaceMatchProgressBar from FaceLivenessDetector so the progress bar can be rendered in isolation. No visual change. The recorded baselines document three existing problems, all in light theme, where background resolves to Color.White against the white scrim: - the recording indicator has no container - the cancel button has no container - the progress bar track is invisible, hiding the remaining distance They also record that the instruction chip, recording indicator and cancel button all read background/onBackground, so none can be restyled alone.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #335 +/- ##
==========================================
+ Coverage 37.41% 40.68% +3.26%
==========================================
Files 123 124 +1
Lines 5019 5027 +8
Branches 707 708 +1
==========================================
+ Hits 1878 2045 +167
+ Misses 2948 2775 -173
- Partials 193 207 +14 🚀 New features to boost your workflow:
|
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.
Issue #, if available: #333
Description of changes:
Adds the first screenshot tests for the liveness module. No production behaviour or appearance changes — this PR only establishes the visual baselines that a follow-up colour-role fix will be reviewed against.
The module already has the Roborazzi infrastructure wired up (
ScreenshotConventionPluginviaamplify.android.ui.component, plustestImplementation(projects.testing)), but no UI tests used it.Why the existing previews weren't enough. The
@Previews inInstructionMessage.kt,RecordingIndicator.ktandCancelChallengeButton.ktrender each element on the preview's own surface. The contrast problems in these elements only appear against the backdrop they are really drawn over, so previews cannot show them. Each test here reproduces the real pairing instead, driven by actualLivenessCheckStatevalues:connecting and verifying over camera feedfaceGuideRectis null in these states, soFaceGuidedraws no scrimcheck running over white scrimFaceGuidescrim, with the oval cut outstart view over themed backdropcolorScheme.backgroundphotosensitivity warning banner/dialogAlertDialog, which derives its text colours fromonSurface/onSurfaceVariantimplicitlyrestyling the instruction chip also restyles other chromeWhat the baselines document. Three problems, all in light theme, all where
backgroundresolves toColor.Whiteagainst the white scrim:Dark theme renders all three correctly.
The last test records the coupling itself: setting
background/onBackgroundto restyle the instruction chip also recolours the recording indicator label and the cancel icon, because all three read the same two roles.A correction to #333. That issue claims a dark-theme defect where the instruction chip renders
#0D1926on aColor.Blackbackdrop during Connecting and Verifying. Theconnecting and verifying over camera feedbaseline shows that isn't so.FaceGuidefills the canvas with itsbackgroundColorand punches out the oval, but it is only composed insidelivenessState.faceGuideRect?.let { }. In those two statesfaceGuideRectis null, so there is no scrim and the chip sits on the live camera feed, where an opaque container reads fine in either theme.Color.Blackonly fills the letterbox bands outside the viewport, and no chrome is drawn there. I'll update the issue.How did you test these changes?
./gradlew :liveness:testDebugUnitTest :liveness:ktlintCheck :liveness:apiCheck— 44 tests pass. Baselines recorded with:liveness:recordRoborazziDebugand confirmed byte-identical to the rendering beforeFaceMatchProgressBarwas extracted.Documentation update required?
General Checklist
fix(liveness): message,fix(authenticator): message,fix(all): message)By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.