Skip to content

test(liveness): add screenshot coverage for overlay chrome - #335

Draft
mattcreaser wants to merge 1 commit into
mainfrom
mattcreaser/liveness-chrome-screenshots
Draft

mattcreaser wants to merge 1 commit into
mainfrom
mattcreaser/liveness-chrome-screenshots

Conversation

@mattcreaser

Copy link
Copy Markdown
Member

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 (ScreenshotConventionPlugin via amplify.android.ui.component, plus testImplementation(projects.testing)), but no UI tests used it.

Why the existing previews weren't enough. The @Previews in InstructionMessage.kt, RecordingIndicator.kt and CancelChallengeButton.kt render 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 actual LivenessCheckState values:

Test Backdrop
connecting and verifying over camera feed live camera feed — faceGuideRect is null in these states, so FaceGuide draws no scrim
check running over white scrim the white FaceGuide scrim, with the oval cut out
start view over themed backdrop colorScheme.background
photosensitivity warning banner / dialog guards the AlertDialog, which derives its text colours from onSurface/onSurfaceVariant implicitly
restyling the instruction chip also restyles other chrome records the role sharing reported in #333

What the baselines document. Three problems, all in light theme, all where background resolves to Color.White against the white scrim:

  • the recording indicator has no container, leaving a bare red dot and label
  • the cancel button has no container, leaving a bare X
  • the progress bar track is invisible, so the remaining distance to the oval cannot be seen

Dark theme renders all three correctly.

The last test records the coupling itself: setting background/onBackground to 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 #0D1926 on a Color.Black backdrop during Connecting and Verifying. The connecting and verifying over camera feed baseline shows that isn't so. FaceGuide fills the canvas with its backgroundColor and punches out the oval, but it is only composed inside livenessState.faceGuideRect?.let { }. In those two states faceGuideRect is 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.Black only 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:recordRoborazziDebug and confirmed byte-identical to the rendering before FaceMatchProgressBar was extracted.

Documentation update required?

  • No
  • Yes (Please include a PR link for the documentation update)

General Checklist

  • Added Unit Tests
  • Added Integration Tests
  • Security oriented best practices and standards are followed (e.g. using input sanitization, principle of least privilege, etc)
  • Ensure commit message has the appropriate scope (e.g 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.

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

codecov Bot commented Aug 25, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 60.00000% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 40.68%. Comparing base (3036bb7) to head (2d3a632).

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:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant