Snapshot testování pro mobilní aplikace: jak funguje, nástroje a příklady

Co je snapshot testování?

Snapshot testování (snapshot testing) je technika, při které test vyrenderuje komponentu rozhraní, uloží výsledný obrázek jako referenci a při následujících spuštěních porovnává aktuální render s touto referencí. Pokud se obrázky shodují — test prošel. Pokud jsou nalezeny rozdíly — test selže a vývojář obdrží diff obrázek se zvýrazněním změněných pixelů. Technika je převzata z webového vývoje (Jest snapshots) a adaptována pro mobilní platformy.

Hlavní hodnota snapshot testů spočívá v automatickém odhalování neočekávaných vizuálních změn. Vývojář může změnit barevné schéma v globálním tématu a neúmyslně ovlivnit desítku obrazovek. UI testy kontrolující přítomnost tlačítek a textů si toho nevšimnou. Snapshot test zachytí změnu každého pixelu na každé ovlivněné obrazovce a poskytne úplný obrázek dopadu změny.

Podle průzkumu Mobile DevOps Summit 2023 týmy používající snapshot testování jako doplněk ke klasickým UI testům snižují počet vizuálních defektů v releasech o 40%. Zvláště efektivní je tento přístup v projektech s design systémy a komponentovými přístupy, kde změna jedné základní komponenty může ovlivnit desítky obrazovek aplikace.

Jak se snapshot testy liší od UI testů

Zásadní rozdíl spočívá v předmětu kontroly. UI testy kontrolují přítomnost, stav a chování prvků rozhraní: „tlačítko je viditelné“, „text obsahuje chybovou zprávu“, „po kliknutí se otevře nová obrazovka“. Snapshot testy kontrolují vzhled jako celek: rozmístění prvků, okraje, barvy, písma, stíny a zaoblení. Snapshot test odpovídá na otázku „vypadá obrazovka podle očekávání?“, zatímco UI test — „funguje obrazovka podle očekávání?“

Rychlost provádění se také liší. UI testy běží na emulátoru nebo reálném zařízení, vyžadují úplné načtení aplikace a trvají 10 sekund až minutu na jeden scénář. Snapshot testy založené na knihovnách jako Paparazzi renderují komponentu ve virtuálním prostředí bez spuštění emulátoru, což zkracuje dobu testu na 100–500 milisekund. Celá sada snapshot testů (50–100 obrazovek) se provede za 2–5 minut místo 30–60 minut pro obdobnou sadu UI testů.

Snapshot testy však nenahrazují UI testy. Optimální strategií je kombinace: snapshot testy pokrývají vizuální regresi (render každé obrazovky v základních stavech) a UI testy — behaviorální (click scénáře, validaci vstupu, navigaci). Tato kombinace poskytuje 90% jistotu korektnosti rozhraní při minimální době CI běhu.

Nástroje pro snapshot testování

Na Androidu jsou hlavními nástroji Paparazzi a Shot. Paparazzi od Cash App renderuje komponenty v testovacím prostředí na JVM bez emulátoru pomocí gravitačního rozložení Layoutlib. Shot od Karumi provádí Instrumentation snímky na reálném zařízení nebo emulátoru a porovnává je s referencemi pomocí knihovny AShot, která zohledňuje rozdíly v rozlišení a hustotě pixelů.

Paparazzi pro Android

Paparazzi nevyžaduje spuštění emulátoru — render probíhá na JVM přes Layoutlib, což poskytuje rychlost srovnatelnou s unit testy. Knihovna podporuje jak View systém, tak Jetpack Compose. Pro Compose se používá modifikátor paparazzi.snapshot { MyComposable() }. Reference jsou uloženy v src/test/snapshots a automaticky porovnávány při každém spuštění. Maximální procento odchylky se nastavuje přes maxPercentDifference.

SnapshotTesting pro iOS

SnapshotTesting od Point-Free podporuje porovnávání nejen UIImage, ale také řetězců, JSON, Data a celých Core Data storeů. Díky tomu je univerzálním nástrojem nejen pro UI snapshots, ale také pro kontrolu serializace a dekódování JSON odpovědí. Pro SwiftUI se používá rozšíření assertSnapshot s modifikátorem .image(on: .iPhone13). Strategie záznamu — record: true — vytváří reference při prvním spuštění.

Multiplatformní přístupy

Pro React Native je populární řešení react-native-testing-library v kombinaci s jest-image-snapshot. Webový přístup k snapshot testování se přenáší do mobilního prostředí pomocí renderu komponent v Node.js prostředí s následným porovnáním JSON snímků virtuálního DOM. Tento přístup je rychlejší než nativní, ale méně přesný — nezohledňuje platformní specifika renderu písem a systémových komponent. Pro Flutter se používá golden testování přes goldens toolkit.

Příklady kódu pro snapshot testy

Podívejme se na snapshot testy pro Android (Paparazzi) a iOS (SnapshotTesting). Oba příklady kontrolují vzhled komponenty — uživatelské karty s avatarem, jménem a stavem. Test renderuje komponentu s testovacími daty a porovnává výsledek s referenčním obrázkem uloženým v repozitáři.

Android: snapshot test s Paparazzi

Paparazzi používá anotaci @Test a metodu snapshot() pro zachycení renderu. Reference jsou uloženy ve složce src/test/snapshots a automaticky načteny při příštím spuštění pro porovnání.

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 s SnapshotTesting

SnapshotTesting používá modifikátor .snapshot() uvnitř assertSnapshot. Knihovna automaticky určuje formát — UIImage pro UIView, String pro text, Data pro binární data.

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))
    }
}

Pracovní postup snapshot testování

Typický pracovní postup zahrnuje čtyři fáze. První spuštění (record mode): všechny snapshot testy běží v režimu záznamu — referenční obrázky jsou vytvořeny a uloženy do repozitáře. Tato fáze se provádí při počátečním nastavení testů nebo po vědomé změně rozhraní. Po záznamu jsou reference commitnuty spolu s kódem — stávají se součástí projektu.

Při následujících spuštěních testy pracují v režimu porovnání: každý nový render je porovnán s referencí. Pokud jsou nalezeny rozdíly, je vygenerován diff obrázek: zeleně jsou zvýrazněny pixely shodující se s referencí, červeně — odlišné. Vývojář prostuduje diff a rozhodne: pokud je změna očekávaná (vědomá změna designu), reference se aktualizuje příkazem record; pokud je neočekávaná — opraví se chyba. Aktualizace referencí se provádí jedním příkazem: pro Paparazzi je to `./gradlew recordPaparazzi`, pro SnapshotTesting — `assertSnapshot(record: true)`.

Podle Spotify Engineering Blog (2022) týmy používající popsaný pracovní postup stráví analýzou diff obrázků v průměru 2 minuty na test. Při sadě 50 snapshot testů trvá celý cyklus aktualizace referencí 15–20 minut, což je výrazně rychlejší než ruční verifikace vizuálních změn na 50 obrazovkách.

Omezení a antipatterny snapshot testů

Snapshot testy mají zásadní omezení. Citlivost na prostředí: stejná komponenta se může vyrenderovat odlišně na různých verzích OS, hustotách obrazovky a konfiguracích písem. Reference vytvořené na jednom stroji se mohou lišit od renderu na CI serveru. Řešení — používat fixní parametry prostředí: konkrétní verzi Layoutlib pro Paparazzi nebo přesný model zařízení pro SnapshotTesting.

Antipattern #1: obří snapshots — snapshot test zachycující celou obrazovku selže při každé sebemenší změně libovolné komponenty. Správný přístup — testovat jednotlivé komponenty (tlačítko, kartu, vstupní pole) izolovaně. Každá komponenta se testuje nezávisle, což poskytuje přesné určení zdroje změny. Antipattern #2: ignorování diffů — automatická aktualizace referencí bez analýzy diff obrázků snižuje hodnotu snapshot testů na nulu. Každý diff vyžaduje vědomé rozhodnutí vývojáře.

Podle Better Engineering Blog (2023) přinášejí snapshot testy největší užitek při pokrytí komponent design systému a klíčových obrazovek v základních stavech — prázdném, vyplněném, chybovém a hraničním. Pokrytí animací a dynamických stavů pomocí snapshot testů je neefektivní kvůli nedeterminismu časových značek v renderu — pro takové scénáře je vhodnější videozáznam nebo manuální QA kontrola.