Screenshot Test: wat is het, types en hoe het werkt in testen

Wat is Screenshot Test en waarom is het nodig?

Screenshot Test — is end-to-end testen van de gebruikersinterface, waarbij de test het app-scherm opent, acties uitvoert (tikken, tekst invoeren, scrollen) en een schermafbeelding maakt van de verkregen toestand. De schermafbeelding wordt vergeleken met een referentie (baseline) die in de repository is opgeslagen. Als de schermafbeeldingen verschillen — faalt de test. Screenshot tests detecteren visuele regressies die niet zichtbaar zijn in unittesten: onjuiste marges, overlappende elementen, verkeerde kleuren.

Waarom screenshot tests nodig zijn als er golden tests zijn — golden tests controleren componenten geïsoleerd: één knop, één kaart, één tekst. Screenshot tests controleren het volledige scherm in een omgeving die zo dicht mogelijk bij productie ligt: echte navigatie, echte gegevens (of zo realistisch mogelijke mocks), echte systeemlettertypen, echte statusbalk. Alleen een screenshot test laat zien dat een knop over een ander element heen valt op een echt apparaat.

Bedrijfswaarde van screenshot tests

Bedrijfswaarde — volgens Google (2023) vormen visuele bugs 15-25% van alle bugs in mobiele apps. Screenshot tests automatiseren de visuele kwaliteitscontrole die voorheen handmatig door QA-ingenieurs werd gedaan. Eén screenshot test vervangt 5-10 minuten handmatig testen van één scherm. Voor een app met 50 schermen: besparing van 4-8 mensuren per regressierun. Screenshot tests verdienen zich terug binnen 2-3 releasecycli.

Screenshot Test vs Golden Test: vergelijking van benaderingen

Golden tests zijn sneller en eenvoudiger: het renderen van een component in een off-screen buffer duurt milliseconden, vereist geen apparaat, zijn stabiel op CI. Screenshot tests zijn realistischer: ze leggen het echte scherm vast met systeemelementen, ondersteunen animaties en navigatie, werken op echte apparaten. De keuze hangt af van het doel: snelle feedback voor de ontwikkelaar (golden) of maximale realisme vóór de release (screenshot).

Dekkingsstrategie: golden + screenshot

Golden + Screenshot — gebruik golden tests voor elke UI-component in de componentenbibliotheek (Design System). 80% van de visuele regressies worden op componentniveau opgevangen. Screenshot tests — voor kritieke gebruikerspaden: onboarding, inloggen, betalingsflow, winkelmand. 20% van de regressies gerelateerd aan componentintegratie op het echte scherm worden alleen door screenshot tests opgevangen. Bij IT Sectr gebruiken we de verhouding 80/20: 400 golden + 100 screenshot.

Wanneer een screenshot test niet nodig is — als het scherm uit statische inhoud zonder interactiviteit bestaat, biedt een golden test van de component hetzelfde niveau van controle tegen lagere kosten. Als het scherm dynamisch verandert (feed, chat), vereist een screenshot test complexe gegevensconfiguratie en wachttijd. Gebruik in zulke gevallen screenshot voor de basisstatus (lege lijst, laden) en golden voor individuele kaarten in de lijst.

UI Automator en Firebase Test Lab voor Android

UI Automator — Android-framework voor cross-app UI-testen. Maakt schermafbeeldingen mogelijk via UiDevice.takeScreenshot(). In tegenstelling tot Espresso (werkt binnen één app) kan UI Automator interageren met systeemdialoogvensters (machtigingen, meldingen) en andere apps. Screenshot test op UI Automator: open de app, wacht op laden, maak een schermafbeelding, vergelijk met de referentie.

class LoginScreenScreenshotTest {

    @get:Rule
    val rule = ComposeTestRule.createAndroidComposeRule<MainActivity>()

    @Test
    fun login_screen_default() {
        val device = UiDevice.getInstance(
            InstrumentationRegistry.getInstrumentation()
        )

        // Wachten op het laden van het scherm
        IdlingRegistry.getInstance().waitForIdle()

        // Schermafbeelding maken
        val screenshot = device.takeScreenshot()
        val golden = loadGolden("login_default.png")

        // Vergelijken met de referentie
        val diff = ImageComparator.compare(screenshot, golden)
        assertTrue(diff.similarity > 0.98)
    }
}

Firebase Test Lab — Google Cloud-service voor het parallel uitvoeren van instrumentele tests op honderden echte apparaten. Screenshot tests op Firebase Test Lab leggen schermafbeeldingen vast op verschillende apparaten (Pixel 7, Galaxy S24, Xiaomi 14) en vergelijken ze met referenties. Voordeel: één test controleert UI op 20 apparaten in 10-15 minuten. Nadeel: kosten ($1-5 per test op 20 apparaten). Firebase Test Lab integreert met CI via gcloud CLI of Gradle-plugin.

Shot: bibliotheek voor vereenvoudiging van screenshot tests

Shot — bibliotheek voor screenshot testen op Android, die het maken en vergelijken van schermafbeeldingen vergemakkelijkt. Shot werkt op basis van Espresso en UI Automator, en voegt golden-beheer (aanmaken, bijwerken, verwijderen), vergelijking met drempelwaarde (pixels of percentages) en het genereren van HTML-rapporten toe. Shot is geschikt voor projecten die snel screenshot testen willen implementeren zonder eigen infrastructuur voor beeldvergelijking te schrijven.

XCUITest en Xcode Cloud voor iOS

XCUITest — Apple-framework voor UI-testen van iOS-, iPadOS- en tvOS-apps. Screenshot tests op XCUITest gebruiken XCUIScreen.main.screenshot() voor het vastleggen van het scherm en XCAttachment voor het opslaan van de schermafbeelding. XCUITest simuleert gebruikersacties: tap, swipe, typeText, en maakt na elke stap schermafbeeldingen. In Xcode 16+ is ingebouwde ondersteuning toegevoegd voor het vergelijken van schermafbeeldingen met referenties via XCTAttachment.

final class LoginScreenScreenshotTests: XCTestCase {

    var app: XCUIApplication!

    override func setUp() {
        super.setUp()
        app = XCUIApplication()
        app.launch()
    }

    func test_login_initial_state() {
        let loginButton = app.buttons["login_button"]
        XCTAssertTrue(loginButton.exists)

        // Schermafbeelding maken
        let screenshot = app.screenshot()
        let attachment = XCTAttachment(screenshot: screenshot)
        attachment.name = "Login-Screen-Initial"
        attachment.lifetime = .keepAlways
        add(attachment)

        // Vergelijking met referentie (vereist XCTAttachment + golden)
        assertScreenshot(
            screenshot: screenshot,
            goldenName: "login_initial_state"
        )
    }
}

Xcode Cloud — cloud-CI van Apple voor het bouwen en testen van iOS-apps. Xcode Cloud ondersteunt het uitvoeren van XCUITest-tests op simulators. Screenshot tests kunnen parallel op meerdere simulators worden uitgevoerd (iPhone 15, iPhone 15 Pro Max, iPad Pro). Resultaten: XCResult Bundle met bijlagen. Xcode Cloud is niet ingebouwd in GitHub/GitLab — gebruik Xcode Cloud Webhooks voor integratie. Alternatief: GitHub Actions met macos-14 en xcodebuild.

Vergelijkingsframeworks — iOSSnapshotTestCase (Uber) werkt ook voor screenshot tests als het op een simulator wordt uitgevoerd. SwiftSnapshotTesting (pointfree) is meer gericht op golden tests van componenten. Voor screenshot tests op iOS gebruik je de ingebouwde tools XCUITest + XCTAttachment + een aangepaste ImageComparator (Pixelmator of AImage). Op CI gebruik je een simulator — op echte apparaten werken screenshot tests alleen via Device Farm (AWS Device Farm).

Automatiseringsproces van screenshot tests in CI

Baseline-beheer — referentie-schermafbeeldingen worden opgeslagen in de repository (Git LFS) of in S3. Elke schermafbeelding wordt benoemd volgens het sjabloon: {testName}_{device}_{orientation}_{locale}.png. Voorbeeld: loginScreenPixel7PortraitRu.png. Bij toevoeging van een nieuw apparaat of locale wordt een nieuwe baseline aangemaakt. Bij wijziging van de UI worden oude baselines vervangen door nieuwe na code review. De baseline is onderdeel van de codebasis, net als de testbronnen.

CI Pipeline — (1) App bouwen. (2) Screenshot tests uitvoeren op emulators/simulators. (3) Schermafbeeldingen vergelijken met baseline. (4) Bij niet-overeenkomst — diff-afbeelding genereren. (5) Diff-artefacten uploaden (actual, expected, diff — drie bestanden). (6) HTML-rapport publiceren met resultatentabel. (7) Als drempelwaarde wordt overschreden — test faalt. (8) Reviewer bekijkt de diff-artefacten en neemt een beslissing: goedkeuren (baseline bijwerken) of afwijzen (code repareren).

Drempelwaarde en tolerantie — absolute pixel-voor-pixel-vergelijking is te streng. Gebruik SSIM (Structural Similarity Index) of MSE (Mean Squared Error). SSIM 0.98 = 98% structurele gelijkenis — een goede drempelwaarde. Voor verschillende schermen kunnen verschillende drempelwaarden nodig zijn: donkere modus (meer zwart — hogere nauwkeurigheid), verloop (meer ruis — lagere nauwkeurigheid). Configureer de drempelwaarde per-test via parameter: @ScreenshotTest(threshold = 0.99).

Device Farm vs Simulator — tests op echte apparaten (Firebase Test Lab, AWS Device Farm) geven maximaal realisme, maar zijn traag en betaald. Tests op simulators/emulators — snel en gratis, maar tonen geen echte apparaatkenmerken (verschillende GPU’s, kleurweergave van het scherm, pixeldichtheid). Strategie: simulator voor pre-merge-controle (5 minuten), Device Farm voor nightly (30 minuten, 20 apparaten). Bij IT Sectr gebruiken we Firebase Test Lab voor nachtelijke runs op de top-10 Android-apparaten.