Snapshottestning för mobila applikationer: hur det fungerar, verktyg och exempel

Vad är snapshottestning?

Snapshottestning (snapshot testing) är en teknik där testet renderar en gränssnittskomponent, sparar den resulterande bilden som referens och vid efterföljande körningar jämför den aktuella renderingen med denna referens. Om bilderna matchar — godkänns testet. Om skillnader upptäcks — misslyckas testet och utvecklaren får en diff-bild med markerade ändrade pixlar. Tekniken är hämtad från webbutveckling (Jest snapshots) och anpassad för mobila plattformar.

Det främsta värdet med snapshot-tester är automatisk upptäckt av oväntade visuella förändringar. En utvecklare kan ändra färgschemat i ett globalt tema och oavsiktligt påverka ett dussintal skärmar. UI-tester som kontrollerar förekomsten av knappar och texter märker inte detta. Ett snapshot-test fångar förändringen av varje pixel på varje påverkad skärm och ger en fullständig bild av ändringens påverkan.

Enligt en undersökning från Mobile DevOps Summit 2023 minskar team som använder snapshottestning som komplement till klassiska UI-tester antalet visuella defekter i releaser med 40%. Särskilt effektiv är denna metod i projekt med designsystem och komponentbaserade tillvägagångssätt, där en ändring av en grundläggande komponent kan påverka dussintals skärmar i applikationen.

Hur skiljer sig snapshot-tester från UI-tester

Den grundläggande skillnaden ligger i kontrollobjektet. UI-tester kontrollerar förekomsten, tillståndet och beteendet hos gränssnittselement: “knappen är synlig”, “texten innehåller felmeddelande”, “efter klick öppnas en ny skärm”. Snapshot-tester kontrollerar utseendet som helhet: elementplacering, marginaler, färger, typsnitt, skuggor och rundningar. Ett snapshot-test svarar på frågan “ser skärmen ut som förväntat?”, medan ett UI-test svarar på “fungerar skärmen som förväntat?”

Utförandehastigheten skiljer sig också. UI-tester körs på emulator eller verklig enhet, kräver fullständig inläsning av applikationen och tar 10 sekunder till en minut per scenario. Snapshot-tester baserade på bibliotek som Paparazzi renderar komponenten i en virtuell miljö utan att starta emulatorn, vilket förkortar testtiden till 100–500 millisekunder. En fullständig uppsättning snapshot-tester (50–100 skärmar) utförs på 2–5 minuter istället för 30–60 minuter för en motsvarande uppsättning UI-tester.

Snapshot-tester ersätter dock inte UI-tester. Den optimala strategin är en kombination: snapshot-tester täcker visuell regression (rendering av varje skärm i grundläggande tillstånd) och UI-tester täcker beteendemässig (klickscenarier, inmatningsvalidering, navigering). Denna kombination ger 90% säkerhet för gränssnittets korrekthet med minimal CI-körtid.

Verktyg för snapshottestning

På Android är de främsta verktygen Paparazzi och Shot. Paparazzi från Cash App renderar komponenter i testmiljö på JVM utan emulator med hjälp av gravitationslayouten Layoutlib. Shot från Karumi utför Instrumentation-skärmbilder på verklig enhet eller emulator och jämför dem med referenser via biblioteket AShot, som tar hänsyn till skillnader i upplösning och pixeltäthet.

Paparazzi för Android

Paparazzi kräver inte att emulatorn startas — renderingen utförs på JVM via Layoutlib, vilket ger hastighet jämförbar med enhetstester. Biblioteket stöder både View-systemet och Jetpack Compose. För Compose används modifieraren paparazzi.snapshot { MyComposable() }. Referenser lagras i src/test/snapshots och jämförs automatiskt vid varje körning. Den maximala skillnadsprocenten ställs in via maxPercentDifference.

SnapshotTesting för iOS

SnapshotTesting från Point-Free stöder jämförelse inte bara av UIImage utan också av strängar, JSON, Data och hela Core Data-lager. Detta gör det till ett universellt verktyg inte bara för UI-snapshots utan också för kontroll av serialisering och avkodning av JSON-svar. För SwiftUI används tillägget assertSnapshot med modifieraren .image(on: .iPhone13). Inspelningsstrategin — record: true — skapar referenser vid första körningen.

Plattformsoberoende metoder

För React Native är den populära lösningen react-native-testing-library i kombination med jest-image-snapshot. Webbmetoden för snapshottestning överförs till mobilmiljön genom rendering av komponenter i Node.js-miljö med efterföljande jämförelse av JSON-ögonblicksbilder av virtuella DOM. Denna metod är snabbare än den inbyggda men mindre exakt — den tar inte hänsyn till plattformsspecifika egenskaper vid rendering av typsnitt och systemkomponenter. För Flutter används golden-testning via goldens toolkit.

Kodexempel för snapshot-tester

Låt oss titta på snapshot-tester för Android (Paparazzi) och iOS (SnapshotTesting). Båda exemplen kontrollerar utseendet på en komponent — ett användarkort med avatar, namn och status. Testet renderar komponenten med testdata och jämför resultatet med referensbilden som lagrats i databasen.

Android: snapshot-test med Paparazzi

Paparazzi använder anteckningen @Test och metoden snapshot() för att fånga renderingen. Referenser lagras i mappen src/test/snapshots och laddas automatiskt vid nästa körning för jämförelse.

class UserCardSnapshotTest {

    @get:Rule
    val paparazzi = Paparazzi(
        theme = "Theme.MyApp",
        maxPercentDifference = 0.1
    )

    @Test
    fun userCard_defaultState() {
        val card = UserCard(
            name = "Alice Johnson",
            status = "Online",
            avatarUrl = "https://example.com/avatar.png"
        )
        paparazzi.snapshot(card)
    }

    @Test
    fun userCard_offlineState() {
        val card = UserCard(
            name = "Bob Smith",
            status = "Offline",
            avatarUrl = null
        )
        paparazzi.snapshot(card, name = "user_card_offline")
    }
}

iOS: snapshot-test med SnapshotTesting

SnapshotTesting använder modifieraren .snapshot() inuti assertSnapshot. Biblioteket bestämmer automatiskt formatet — UIImage för UIView, String för text, Data för binärdata.

import SnapshotTesting
import XCTest

class UserCardSnapshotTests: XCTestCase {
    func testUserCardDefaultState() {
        let card = UserCardView(
            name: "Alice Johnson",
            status: "Online",
            avatarURL: URL(string: "https://example.com/avatar.png")
        )
        let controller = UIHostingController(rootView: card)
        assertSnapshot(matching: controller, as: .image(on: .iPhone13))
    }

    func testUserCardOfflineState() {
        let card = UserCardView(
            name: "Bob Smith",
            status: "Offline",
            avatarURL: nil
        )
        assertSnapshot(matching: card, as: .image(on: .iPhone13))
    }
}

Arbetsflöde för snapshottestning

Ett typiskt arbetsflöde omfattar fyra steg. Första körningen (record mode): alla snapshot-tester körs i inspelningsläge — referensbilder skapas och sparas i databasen. Detta steg utförs vid initial konfiguration av tester eller efter en medveten gränssnittsändring. Efter inspelning committas referenserna tillsammans med koden — de blir en del av projektet.

Vid efterföljande körningar arbetar testerna i jämförelseläge: varje ny rendering jämförs med referensen. Om skillnader upptäcks genereras en diff-bild: grönt markerar pixlar som matchar referensen, rött — avvikande. Utvecklaren studerar diffen och fattar beslut: om ändringen är förväntad (medveten designändring) uppdateras referensen med kommandot record; om oväntad — åtgärdas felet. Uppdatering av referenser utförs med ett enda kommando: för Paparazzi är det `./gradlew recordPaparazzi`, för SnapshotTesting — `assertSnapshot(record: true)`.

Enligt Spotify Engineering Blog (2022) lägger team som använder det beskrivna arbetsflödet i genomsnitt 2 minuter per test på att analysera diff-bilder. Med en uppsättning av 50 snapshot-tester tar hela referensuppdateringscykeln 15–20 minuter, vilket är betydligt snabbare än manuell verifiering av visuella ändringar på 50 skärmar.

Begränsningar och anti-mönster för snapshot-tester

Snapshot-tester har grundläggande begränsningar. Känslighet för miljön: samma komponent kan renderas olika på olika OS-versioner, skärmdensiteter och teckensnittskonfigurationer. Referenser skapade på en maskin kan skilja sig från renderingen på en CI-server. Lösning — använd fasta miljöparametrar: specifik version av Layoutlib för Paparazzi eller exakt enhetsmodell för SnapshotTesting.

Anti-mönster #1: gigantiska snapshots — ett snapshot-test som fångar hela skärmen misslyckas vid varje minsta ändring av någon komponent. Rätt tillvägagångssätt är att testa enskilda komponenter (knapp, kort, inmatningsfält) isolerat. Varje komponent testas oberoende, vilket ger exakt indikation på ändringskällan. Anti-mönster #2: ignorering av differ — automatisk uppdatering av referenser utan analys av diff-bilder reducerar värdet av snapshot-tester till noll. Varje diff kräver ett medvetet beslut av utvecklaren.

Enligt Better Engineering Blog (2023) ger snapshot-tester störst nytta när de täcker komponenter i designsystemet och nyckelskärmar i grundläggande tillstånd — tomt, ifyllt, felaktigt och gränsöverskridande. Täckning av animationer och dynamiska tillstånd via snapshot-tester är ineffektivt på grund av icke-deterministiska tidsstämplar i renderingen — för sådana scenarier är videoinspelning eller manuell QA-kontroll mer lämplig.