Golden Test — ano ito, paano gumagana ang snapshot-testing at aplikasyon

Ano ang Golden Test at paano ito gumagana?

Golden Test — ay isang awtomatikong pagsusuri ng hitsura ng component sa pamamagitan ng paghahambing pixel-por-pixel sa sanggunian. Proseso: (1) ang developer o tester ay kumukuha ng unang screenshot ng component — ito ang “golden” (sanggunian). (2) Ang golden-file ay nai-save sa repositoryo sa tabi ng pagsubok. (3) Sa mga susunod na pagpapatakbo, ang pagsubok ay nagre-render muli ng component at inihahambing sa nai-save na golden. (4) Kung magkatugma ang mga larawan — berde ang pagsubok. Kung magkaiba — pula ang pagsubok na may diff. Desisyon: alinman ang mga pagbabago ay inaasahan (ina-update namin ang golden) o ito ay isang bug.

Paano nabubuo ang golden — ang library ay nagre-render ng component sa off-screen buffer (Android: Canvas, iOS: UIGraphicsImageRenderer) nang walang tunay na display. Ito ay nangangahulugan na ang golden-test ay gumagana sa CI nang walang emulator ng screen (virtual display), na nagpapabilis ng pagpapatupad. Ang Paparazzi sa Android ay gumagamit ng Layoutlib mula sa Android Studio — ang parehong engine ng Layout Editor. Ang iOSSnapshotTestCase ay gumagamit ng UIKit rendering sa CGImage. Resulta — isang PNG file na may nakapirming laki.

Sukat ng mga golden-file at pamamahala ng imbakan

Golden-file — PNG screenshot ng isang screen (1080x1920) ay sumasakop ng 200-800 KB depende sa pagiging kumplikado. Para sa isang proyekto na may 500 golden-test ito ay ~100-400 MB sa repositoryo. Mga solusyon: (1) mag-imbak ng golden sa Git LFS. (2) Gumamit ng PNG compression (pngcrush, oxipng). (3) Mag-imbak ng golden sa hiwalay na imbakan (S3) at kunin sa build. Sa IT Sectr nag-iimbak kami ng golden sa Git LFS na may threshold na 1 MB bawat file — ito ay sapat para sa 90% ng mga pagsubok.

Flaky golden test at ang kanilang solusyon

Flaky golden test — pangunahing problema ng golden-test. Iba't ibang GPU, bersyon ng font at anti-aliasing ay nagbibigay ng micro-pagkakaiba sa mga pixel. Mga solusyon: threshold (pinapayagang porsyento ng iba't ibang pixel), fuzzy comparison (malabong paghahambing), at pagpapatakbo sa magkaparehong CI agent (parehong GPU, OS, bersyon ng emulator). Sa Paparazzi ginagamit ang pixel-perfect na paghahambing, kaya ang mga CI agent ay dapat magkapareho.

Golden Test vs Screenshot Test: ano ang pagkakaiba?

Golden Test — ay isang uri ng screenshot-testing na may nakapirming sanggunian. Ang terminong “golden” ay nangangahulugan na ang sanggunian ay naaprubahan (tinanggap) ng koponan at naka-imbak sa repositoryo. Ang bawat pagbabago sa larawan ay nangangailangan ng malay na desisyon ng developer: i-update ang golden o ayusin ang code. Ang Golden Test ay gumagana sa antas ng mga indibidwal na component (Composable, UIView) at hindi nangangailangan ng tunay na aparato.

Screenshot Test — mas malawak na konsepto. Ang Screenshot-test ay maaaring kumuha ng buong screen na may tunay na data, nabigasyon, status bar ng system at mga animation. Ang Screenshot-test ay madalas na tumatakbo sa mga tunay na aparato o emulator sa pamamagitan ng UI Automator (Android) o XCUITest (iOS). Ang Golden-test ay gumagana sa unit-test na kapaligiran (JVM, XCTest) nang walang emulator at kumukuha lamang ng isang component.

Estratehiya ng saklaw: golden vs screenshot

Golden vs Screenshot — golden-test para sa pagsusuri ng mga indibidwal na UI component (button, card, dialog) sa bawat commit. Screenshot-test — para sa E2E pagsusuri ng buong screen bago ilabas. Ang Golden-test ay nagbibigay ng mabilis na feedback sa developer, screenshot-test — kumpiyansa sa integridad ng buong application. Sa IT Sectr gumagamit kami ng golden-test para sa Pull Request (3-5 minuto), at screenshot-test para sa nightly (30-60 minuto).

Paparazzi at Roborazzi: snapshot-testing sa Android

Paparazzi — library mula sa Cash App (Square) na nagre-render ng Android View at Jetpack Compose component sa PNG nang walang emulator. Gumagamit ng Layoutlib (parehong engine ng Android Studio Preview). Setup: ikonekta ang Gradle plugin, sumulat ng pagsubok na may @Test at @RunWith(PaparazziRule::class), tawagan ang paparazzi.snapshot(view). Hindi sinusuportahan ng Paparazzi ang mga animation, video at Real Device — tanging static na render ng mga component.

// build.gradle.kts (module)
plugins {
    id("app.cash.paparazzi") version "1.3.1"
}

// Golden test para sa Compose component
class ButtonGoldenTest {

    @get:Rule
    val paparazzi = Paparazzi(
        Paparazzi.PaparazziSnapshotConfig(
            deviceConfig = DeviceConfig.PIXEL_6,
            theme = "android:Theme.Material.Light.NoActionBar"
        )
    )

    @Test
    fun primary_button() {
        paparazzi.snapshot {
            Button(
                onClick = { },
                modifier = Modifier.width(200.dp)
            ) {
                Text("Submit")
            }
        }
    }
}

Roborazzi — alternatibo sa Paparazzi na may suporta para sa Compose, View at paghahambing ng larawan. Pagkakaiba: Ang Roborazzi ay gumagana sa pamamagitan ng Robolectric at sumusuporta sa threshold (porsyento ng pinapayagang pagkakaiba ng pixel). Binabawasan nito ang flakiness sa iba't ibang GPU sa CI. Ang Roborazzi ay maaari ring lumikha ng GIF animation ng mga pagbabago (bago/pagkatapos/diff), na maginhawa para sa code review. Format ng golden-file: PNG + JSON metadata.

Pag-update ng golden — pagkatapos ng sinadyang pagbabago ng UI, tinatanggal ng developer ang mga lumang golden-file at pinapatakbo ang mga pagsubok na may record flag. Muling ginagawa ng Paparazzi ang lahat ng golden-file. Pagkatapos ay nagko-commit ang developer ng bagong golden kasama ang pagbabago ng code. Sa Code Review nakikita ng reviewer ang diff ng luma at bagong golden. Kung naaprubahan ang mga pagbabago — ang PR ay na-merge. Kung hindi — inaayos ng developer ang code at muling pinapatakbo ang mga pagsubok. Huwag kailanman i-update ang golden nang awtomatiko sa CI — lokal lamang.

SwiftSnapshotTesting at iOSSnapshotTestCase sa iOS

SwiftSnapshotTesting — library mula sa pointfree.co, mga lumikha ng Composable Architecture. Sumusuporta sa UIView, UIViewController, CALayer at SwiftUI View. Prinsipyo: assertSnapshot(matching: view, as: .image). Sa unang pagpapatakbo, ang golden ay awtomatikong nilikha. Sa mga susunod — inihahambing. Kung ang pagkakaiba ay lumampas sa pinapayagan — ang pagsubok ay nabibigo. Ang SwiftSnapshotTesting ay gumagana sa pamamagitan ng UIGraphicsImageRenderer, na katugma sa CI (Xcode Cloud, GitHub Actions).

import SnapshotTesting
import XCTest

final class ProfileCardSnapshotTests: XCTestCase {

    func test_profile_card_default() {
        let card = ProfileCard(
            name: "Alice",
            avatar: UIImage.testImage(),
            badge: "Pro"
        )
        let controller = UIHostingController(rootView: card)

        assertSnapshot(
            matching: controller,
            as: .image(on: .iPhoneSe),
            record: ProcessInfo.processInfo
                .environment["RECORD"] != nil
        )
    }
}

iOSSnapshotTestCase (dating FBSnapshotTestCase) — library mula sa Uber para sa UIKit. Hindi tulad ng SwiftSnapshotTesting, ang iOSSnapshotTestCase ay nangangailangan ng pagtukoy ng laki ng screen at oryentasyon. Golden-file — PNG sa folder ng ReferenceImages. Kalamangan: gumagana sa UIKit nang walang SwiftUI at sumusuporta sa iOS 12+. Disbentaha: hindi awtomatikong nag-a-update ng golden — kailangang patakbuhin na may record flag. Ang SwiftSnapshotTesting ay mas moderno at inirerekomenda para sa mga bagong proyekto.

Device-specific golden — ang golden-file ay nag-iiba para sa iba't ibang laki ng screen at oryentasyon. Karaniwang approach: pangalanan ang golden bilang TestName@3x~iPhone14.png. Ang SwiftSnapshotTesting ay awtomatikong nagdaragdag ng suffix ng aparato kung ang parameter .image(on: .iPhoneSe) ay ibinigay. Sa Android, ang Paparazzi ay gumagamit ng DeviceConfig para sa pagtatakda ng laki. Mag-imbak ng golden para sa bawat suportadong device form factor nang hiwalay. Huwag gumamit ng isang golden para sa iba't ibang laki — ito ay hahantong sa flaky test.

Pagtatrabaho sa mga golden-file sa CI at pamamahala ng mga update

CI pipeline — ang golden-test ay dapat tumakbo sa bawat Pull Request. Kung ang pagsubok ay nabigo, ang CI ay nagpapakita ng diff-larawan bilang build artifact. Sinusuri ng developer ang diff at gumagawa ng desisyon. Mahalaga: ang golden-file na nabuo sa CI ay hindi kailanman awtomatikong nako-commit. Tanging lokal na pagbuo ng developer pagkatapos ng sinadyang pagbabago. Sinusuportahan ng GitHub Actions at GitLab CI ang pag-upload ng mga artifact (png, html) para sa pagtingin ng diff sa browser.

Sukat ng repositoryo — ang golden-file ay mabilis na lumalaki. 500 pagsubok = 100-400 MB PNG. Mga solusyon: (1) Git LFS — bawat golden ay naka-imbak sa LFS, naka-clone lamang sa checkout. (2) Mag-imbak ng golden sa hiwalay na repositoryo at ikonekta bilang submodule. (3) S3 + caching — golden sa S3, CI ay nagda-download lamang ng mga binagong file ayon sa checksum. Sa IT Sectr gumagamit kami ng Git LFS na may track *.png filter=lfs diff=lfs merge=lfs text=false. Lokal, ang golden ay nasa src/test/goldens/.

Code Review ng golden — ang karaniwang git diff ay hindi nagpapakita ng mga pagbabago sa PNG. Mga solusyon: (1) Binubuksan ng GitHub ang mga PNG na larawan sa pag-click. (2) Gumamit ng Review Apps, kung saan ang golden-diff ay nakikita sa browser. (3) Bumuo ng HTML report na may mga column bago/pagkatapos/diff. Ang Paparazzi ay lumilikha ng HTML report na may tatlong column: actual, expected, diff. Ang report ay naka-attach sa CI artifact. Ang mga reviewer ay tumitingin sa report nang hindi nagda-download ng mga file nang lokal.

Kailan i-update ang golden — pagkatapos lamang ng sinadyang pagbabago ng UI. Pagbabago ng font, kulay, espasyo, icon — golden ay dapat i-update. Pagdagdag ng bagong button, pag-aayos ng mga elemento — golden ay dapat i-update. Pag-aayos ng bug na nagbabago ng anyo — golden ay dapat i-update. Refactoring nang walang pagbabago ng UI — golden ay hindi dapat i-update. Kung ang golden ay nagbabago nang walang pagbabago ng UI code — ito ay isang flaky test na dulot ng kapaligiran, hanapin ang dahilan sa mga CI agent o bersyon ng dependencies.