Screenshot Test : qu’est-ce que c’est, types et fonctionnement dans les tests

Qu’est-ce que le Screenshot Test et pourquoi en a-t-on besoin ?

Screenshot Test est un test d’interface utilisateur de bout en bout où le test ouvre un écran d’application, effectue des actions (tap, saisie de texte, dïilement) et prend une capture d’écran de l’état résultant. La capture est comparée à une référence (baseline) stockée dans le dépôt. Si les captures diffèrent — le test échoue. Les screenshot tests détectent les régressions visuelles que les tests unitaires ne peuvent pas voir : marges incorrectes, éléments superposés, couleurs erronées.

Pourquoi avons-nous besoin de screenshot tests si nous avons des golden tests ? — les golden tests vérifient les composants isolément : un bouton, une carte, un texte. Les screenshot tests vérifient un écran entier dans un environnement aussi proche que possible de la production : navigation réelle, données réelles (ou mocks maximalement réalistes), polices système réelles, barre d’état réelle. Seul un screenshot test montrera qu’un bouton est superposé à un autre élément sur un appareil réel.

Valeur métier des screenshot tests

Valeur métier — selon Google (2023), les bugs visuels représentent 15à25 % de tous les bugs des applications mobiles. Les screenshot tests automatisent la vérification de la qualité visuelle qui était auparavant effectuée manuellement par les ingénieurs QA. Un screenshot test remplace 5à10 minutes de test manuel d’un écran. Pour une application de 50 écrans, l’économie est de 4à8 heures-homme par exécution de régression. Les screenshot tests sont rentabilisés en 2à3 cycles de publication.

Screenshot Test vs Golden Test : comparaison des approches

Les golden tests sont plus rapides et plus simples : le rendu d’un composant dans un buffer hors écran prend des millisecondes, ne nécessite pas d’appareil et est stable sur CI. Les screenshot tests sont plus réalistes : ils capturent un écran réel avec des éléments système, prennent en charge les animations et la navigation, et fonctionnent sur des appareils réels. Le choix dépend de l’objectif : retour rapide pour le développeur (golden) ou réalisme maximal avant la publication (screenshot).

Stratégie de couverture : golden + screenshot

Golden + Screenshot — utilisez les golden tests pour chaque composant d’UI dans la bibliothèque de composants (Design System). 80 % des régressions visuelles sont attrapées au niveau des composants. Les screenshot tests — pour les parcours utilisateur critiques : onboarding, connexion, flux de paiement, panier. 20 % des régressions liées à l’intégration de composants sur un écran réel ne sont attrapées que par les screenshot tests. Chez IT Sectr, nous utilisons un ratio 80/20 : 400 golden + 100 screenshot.

Quand un screenshot test n’est pas nécessaire — si l’écran se compose de contenu statique sans interactivité, un golden test de composant fournit le même niveau de vérification à un coût moindre. Si l’écran change dynamiquement (flux, chat), un screenshot test nécessite une configuration complexe des données et des temps d’attente. Dans ces cas, utilisez screenshot pour l’état de base (liste vide, chargement) et golden pour les cartes individuelles dans la liste.

UI Automator et Firebase Test Lab pour Android

UI Automator est un framework Android pour les tests d’UI inter-applications. Il permet de prendre des captures d’écran via UiDevice.takeScreenshot(). Contrairement à Espresso (fonctionne à l’intérieur d’une seule application), UI Automator peut interagir avec les dialogues système (autorisations, notifications) et d’autres applications. Un screenshot test sur UI Automator : ouvrir l’app, attendre le chargement, prendre une capture, comparer avec la référence.

class LoginScreenScreenshotTest {

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

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

        // Nous attendons le chargement de l'écran
        IdlingRegistry.getInstance().waitForIdle()

        // Nous prenons une capture d'écran
        val screenshot = device.takeScreenshot()
        val golden = loadGolden("login_default.png")

        // Nous comparons avec la référence
        val diff = ImageComparator.compare(screenshot, golden)
        assertTrue(diff.similarity > 0.98)
    }
}

Firebase Test Lab est un service Google Cloud pour exécuter des tests instrumentés sur des centaines d’appareils réels en parallèle. Les screenshot tests sur Firebase Test Lab capturent des écrans sur différents appareils (Pixel 7, Galaxy S24, Xiaomi 14) et les comparent aux références. Avantage : un test vérifie l’UI sur 20 appareils en 10à15 minutes. Inconvénient : coût (1 à 5 $ par test sur 20 appareils). Firebase Test Lab s’intègre au CI via gcloud CLI ou le plugin Gradle.

Shot : bibliothèque pour simplifier les screenshot tests

Shot est une bibliothèque pour les screenshot tests sur Android qui facilite la création et la comparaison de captures d’écran. Shot fonctionne au-dessus d’Espresso et UI Automator, ajoutant la gestion des golden (créer, mettre à jour, supprimer), la comparaison avec seuil (pixels ou pourcentages) et la génération de rapports HTML. Shot convient aux projets qui souhaitent implémenter rapidement les screenshot tests sans écrire leur propre infrastructure de comparaison d’images.

XCUITest et Xcode Cloud pour iOS

XCUITest est le framework d’Apple pour les tests d’UI des applications iOS, iPadOS et tvOS. Les screenshot tests sur XCUITest utilisent XCUIScreen.main.screenshot() pour la capture d’écran et XCAttachment pour sauvegarder les captures. XCUITest simule les actions utilisateur : tap, swipe, typeText, et prend des captures après chaque étape. Dans Xcode 16+, la prise en charge intégrée de la comparaison des captures avec les références via XCTAttachment a été ajoutée.

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)

        // Nous prenons une capture d'écran
        let screenshot = app.screenshot()
        let attachment = XCTAttachment(screenshot: screenshot)
        attachment.name = "Login-Screen-Initial"
        attachment.lifetime = .keepAlways
        add(attachment)

        // Comparaison avec la référence (nécessite XCTAttachment + golden)
        assertScreenshot(
            screenshot: screenshot,
            goldenName: "login_initial_state"
        )
    }
}

Xcode Cloud est le CI cloud d’Apple pour compiler et tester les applications iOS. Xcode Cloud prend en charge l’exécution de tests XCUITest sur des simulateurs. Les screenshot tests peuvent être exécutés sur plusieurs simulateurs en parallèle (iPhone 15, iPhone 15 Pro Max, iPad Pro). Résultats : XCResult Bundle avec pièces jointes. Xcode Cloud n’est pas intégré dans GitHub/GitLab — utilisez Xcode Cloud Webhooks pour l’intégration. Alternative : GitHub Actions avec macos-14 et xcodebuild.

Frameworks de comparaison — iOSSnapshotTestCase (Uber) fonctionne également pour les screenshot tests s’il est exécuté sur un simulateur. SwiftSnapshotTesting (pointfree) est davantage orienté vers les golden tests de composants. Pour les screenshot tests sur iOS, utilisez les outils intégrés de XCUITest + XCTAttachment + un ImageComparator personnalisé (Pixelmator ou AImage). Sur CI, utilisez un simulateur — sur les appareils réels, les screenshot tests ne fonctionnent que via Device Farm (AWS Device Farm).

Processus d’automatisation des screenshot tests dans le CI

Gestion des références — les captures d’écran de référence sont stockées dans le dépôt (Git LFS) ou dans S3. Chaque capture est nommée selon le modèle : {testName}_{device}_{orientation}_{locale}.png. Exemple : loginScreenPixel7PortraitRu.png. Lors de l’ajout d’un nouvel appareil ou d’une nouvelle locale, une nouvelle référence est créée. Lors de la modification de l’UI, les anciennes références sont remplacées par de nouvelles après la revue de code. La référence fait partie de la base de code, comme les sources des tests.

Pipeline CI — (1) Compiler l’application. (2) Exécuter les screenshot tests sur émulateurs/simulateurs. (3) Comparer les captures avec les références. (4) En cas de différence — générer une image diff. (5) Téléverser les artefacts diff (actual, expected, diff — trois fichiers). (6) Publier un rapport HTML avec tableau des résultats. (7) Si le seuil est dépassé — le test échoue. (8) Le relecteur examine les artefacts diff et prend une décision : approuver (mettre à jour la référence) ou rejeter (corriger le code).

Seuil et tolérance — la comparaison absolue pixel par pixel est trop stricte. Utilisez SSIM (Indice de Similarité Structurelle) ou MSE (Erreur Quadratique Moyenne). SSIM 0.98 = 98 % de similarité structurelle — un bon seuil. Différents écrans peuvent nécessiter différents seuils : thème sombre (plus de noir — précision plus élevée), dégradés (plus de bruit — précision plus faible). Configurez le seuil par test via le paramètre : @ScreenshotTest(threshold = 0.99).

Device Farm vs Simulateur — les tests sur appareils réels (Firebase Test Lab, AWS Device Farm) offrent un réalisme maximal mais sont lents et payants. Les tests sur simulateurs/émulateurs sont rapides et gratuits mais ne montrent pas les caractéristiques des appareils réels (GPU différents, reproduction des couleurs de l’écran, densité de pixels). Stratégie : simulateur pour la vérification pre-merge (5 minutes), Device Farm pour les tests nocturnes (30 minutes, 20 appareils). Chez IT Sectr, nous utilisons Firebase Test Lab pour les exécutions nocturnes sur le top 10 des appareils Android.