Protecting Screenshot Tests for AdMob Screens from Ad Nondeterminism

Feed the placeholder in during screenshot tests

From there, you only swap LocalAdRendering for the placeholder during tests. Here is an example using Roborazzi running on Robolectric, but the idea is the same with Paparazzi.

@RunWith(RobolectricTestRunner::class)
@GraphicsMode(GraphicsMode.Mode.NATIVE)
class SettingsScreenScreenshotTest {
 
    @get:Rule val composeRule = createComposeRule()
    @get:Rule val roborazziRule = RoborazziRule(composeRule = composeRule)
 
    @Test
    fun settings_screen_default() {
        composeRule.setContent {
            CompositionLocalProvider(LocalAdRendering provides AdRendering.PLACEHOLDER) {
                AppTheme {
                    SettingsScreen(state = previewSettingsState)
                }
            }
        }
        composeRule.onRoot().captureRoboImage()
    }
}

previewSettingsState is a state fixed for testing. If it contains dates or random elements, pin those to deterministic values too. Sealing off the ad alone is not enough — if any other nondeterministic element remains, the same problem simply resurfaces elsewhere.

Verify the layout contract, not pixel identity

Once the ad becomes a box, you will want to confirm that the box sits at the right size and position. That is not the job of pixel comparison. Assert the layout contract explicitly with semantics-level assertions.

@Test
fun ad_slot_keeps_its_contract() {
    composeRule.setContent {
        CompositionLocalProvider(LocalAdRendering provides AdRendering.PLACEHOLDER) {
            AppTheme { SettingsScreen(state = previewSettingsState) }
        }
    }
 
    // The slot keeps its expected height
    composeRule.onNodeWithTag("ad_slot").assertHeightIsEqualTo(50.dp)
 
    // Elements above and below the ad are neither pushed out nor hidden
    composeRule.onNodeWithText("Settings").assertIsDisplayed()
    composeRule.onNodeWithTag("settings_footer").assertIsDisplayed()
}

Split this way, two questions stand separately. "Do the visible pixels match the baseline?" is answered by the screenshot; "Are the other elements packed correctly around the ad slot?" is answered by the layout assertions. Even when the ad's contents change, neither question wavers. The table below shows how to divide the two.

Where you cannot swap, mask the slot

Sometimes you have to draw the AdView as-is on an emulator — say, an integration test where you want to observe the real load behavior. In that case, exclude only the ad region at comparison time. The slot carries testTag("ad_slot"), so take its position and size and drop that rectangle from the baseline comparison.

// Before comparing, fetch the ad_slot rectangle and pass it as the mask region
val bounds = composeRule.onNodeWithTag("ad_slot")
    .fetchSemanticsNode()
    .boundsInRoot
 
val maskRect = Rect(
    left = bounds.left.toInt(),
    top = bounds.top.toInt(),
    right = bounds.right.toInt(),
    bottom = bounds.bottom.toInt(),
)
// Set maskRect as the exclusion region for your comparison tool

Masking is a last resort. Since nothing inside the excluded rectangle is checked, hold down at least the ad slot's dimensions with a separate assertion. A mask and a layout contract only mean something as a pair.

The instruction for handing diff triage to Antigravity

Reviewing screenshot diffs is quietly time-consuming work. Once the placeholder swap is in place, delegating the first-pass sorting of the remaining diffs to an Antigravity agent lightens the review load considerably. What matters here is telling the agent explicitly to "treat the ad region as not evidence." Left vague, the nondeterminism you sealed off creeps back in from the triage side.

Pin the agent-facing instruction in the repository's AGENTS.md so it does not drift from run to run.

## Screenshot diff triage policy
 
- Read the diff image and first state which region the change occurs in.
- Changes only inside the `ad_slot` rectangle are always treated as
  "ad-origin, no action needed." Never fail on the basis of this region.
- Only when there is a change outside ad_slot, report the point in one or two lines
  as a suspected break.
- When a dimension assertion (height, display, overlap) fails, prioritize
  reporting that failure over the screenshot's appearance.

Antigravity 2.0 is built to draw conclusions from artifacts, so handing it two pieces of evidence — the diff image and the dimension-assertion results — keeps its judgment stable. What a human finally confirms narrows to just the diffs where the agent said "there is a change outside the slot."

What changed after switching the workflow over

In my own operation, before moving to this design, roughly seventy to eighty percent of the screenshot failures around the settings screen were false positives from ad diffs. A red test became the norm, and in review I fell into the habit of re-running rather than opening the diff viewer. The check remained in form only; in substance it had stopped working.

After decoupling the ad rendering policy and adding the layout-contract assertions, ad-origin false positives all but vanished. The diffs that remain are either intended UI changes or breaks I genuinely need to see. What made me willing to open the diff viewer again was knowing that opening it would always mean a meaningful change was waiting.

For the order of adoption, I would suggest putting in only the CompositionLocal decoupling of the ad slot first, then re-recording all your existing screenshot tests once. That alone clears most of the false positives. The layout-contract assertions and the handoff to Antigravity can wait until you have felt that first result.

A single small banner was quietly eroding trust in the whole test suite. Even for just one screen, try pushing the ad out of what you check. I hope this helps with your own implementation, and thank you for reading.