Screenshot Test: o que é, tipos e como funciona em testes

O que é Screenshot Test e para que serve?

Screenshot Test é um teste de interface do usuário end-to-end onde o teste abre uma tela do aplicativo, executa ações (toques, entrada de texto, rolagem) e tira uma captura de tela do estado resultante. A captura é comparada com uma referência (baseline) armazenada no repositório. Se as capturas diferirem — o teste falha. Os screenshot tests detectam regressões visuais que os testes unitários não conseguem ver: margens incorretas, elementos sobrepostos, cores erradas.

Por que precisamos de screenshot tests se temos golden tests? — os golden tests verificam componentes isoladamente: um botão, um cartão, um texto. Os screenshot tests verificam uma tela inteira em um ambiente o mais próximo possível da produção: navegação real, dados reais (ou mocks maximamente realistas), fontes do sistema reais, barra de status real. Apenas um screenshot test mostrará que um botão está sobreposto a outro elemento em um dispositivo real.

Valor comercial dos screenshot tests

Valor comercial — segundo a Google (2023), bugs visuais representam 15-25% de todos os bugs em aplicativos móveis. Os screenshot tests automatizam a verificação de qualidade visual que antes era feita manualmente por engenheiros de QA. Um screenshot test substitui 5-10 minutos de teste manual de uma tela. Para um aplicativo com 50 telas, economia: 4-8 horas-homem por execução de regressão. Os screenshot tests se pagam em 2-3 ciclos de lançamento.

Screenshot Test vs Golden Test: comparação de abordagens

Os golden tests são mais rápidos e simples: renderizar um componente em buffer off-screen leva milissegundos, não requer dispositivo e é estável em CI. Os screenshot tests são mais realistas: capturam uma tela real com elementos do sistema, suportam animações e navegação, e funcionam em dispositivos reais. A escolha depende do objetivo: feedback rápido para o desenvolvedor (golden) ou máximo realismo antes do lançamento (screenshot).

Estratégia de cobertura: golden + screenshot

Golden + Screenshot — use golden tests para cada componente de UI na biblioteca de componentes (Design System). 80% das regressões visuais são capturadas no nível de componente. Screenshot tests — para caminhos críticos do usuário: integração, login, fluxo de pagamento, carrinho de compras. 20% das regressões relacionadas à integração de componentes em uma tela real são capturadas apenas por screenshot tests. Na IT Sectr usamos uma proporção 80/20: 400 golden + 100 screenshot.

Quando um screenshot test não é necessário — se a tela consiste em conteúdo estático sem interatividade, um golden test de componente fornece o mesmo nível de verificação a um custo menor. Se a tela muda dinamicamente (feed, chat), um screenshot test requer configuração complexa de dados e tempos de espera. Nesses casos, use screenshot para o estado base (lista vazia, carregamento) e golden para cartões individuais na lista.

UI Automator e Firebase Test Lab para Android

UI Automator é um framework Android para teste de UI entre aplicativos. Permite tirar capturas de tela via UiDevice.takeScreenshot(). Ao contrário do Espresso (funciona dentro de um único aplicativo), o UI Automator pode interagir com diálogos do sistema (permissões, notificações) e outros aplicativos. Um screenshot test no UI Automator: abrir o app, aguardar carregamento, tirar captura, comparar com referência.

class LoginScreenScreenshotTest {

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

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

                // Aguardamos o carregamento da tela
        IdlingRegistry.getInstance().waitForIdle()

                // Tiramos uma captura de tela
        val screenshot = device.takeScreenshot()
        val golden = loadGolden("login_default.png")

                // Comparamos com a referência
        val diff = ImageComparator.compare(screenshot, golden)
        assertTrue(diff.similarity > 0.98)
    }
}

Firebase Test Lab é um serviço Google Cloud para executar testes instrumentados em centenas de dispositivos reais em paralelo. Os screenshot tests no Firebase Test Lab capturam telas em diferentes dispositivos (Pixel 7, Galaxy S24, Xiaomi 14) e comparam com referências. Vantagem: um teste verifica a UI em 20 dispositivos em 10-15 minutos. Desvantagem: custo ($1-5 por teste em 20 dispositivos). O Firebase Test Lab integra-se com CI via gcloud CLI ou plugin Gradle.

Shot: biblioteca para simplificar screenshot tests

Shot é uma biblioteca para screenshot testing no Android que facilita a criação e comparação de capturas. Shot funciona sobre Espresso e UI Automator, adicionando gerenciamento de golden (criar, atualizar, excluir), comparação com limite (pixels ou porcentagens) e geração de relatório HTML. Shot é adequado para projetos que desejam implementar rapidamente screenshot testing sem escrever sua própria infraestrutura de comparação de imagens.

XCUITest e Xcode Cloud para iOS

XCUITest é o framework da Apple para teste de UI de aplicativos iOS, iPadOS e tvOS. Os screenshot tests no XCUITest usam XCUIScreen.main.screenshot() para capturar a tela e XCAttachment para salvar as capturas. O XCUITest simula ações do usuário: tap, swipe, typeText, e tira capturas após cada etapa. No Xcode 16+, foi adicionado suporte integrado para comparação de capturas com referências 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)

                // Tiramos uma captura de tela
        let screenshot = app.screenshot()
        let attachment = XCTAttachment(screenshot: screenshot)
        attachment.name = "Login-Screen-Initial"
        attachment.lifetime = .keepAlways
        add(attachment)

                // Comparação com a referência (requer XCTAttachment + golden)
        assertScreenshot(
            screenshot: screenshot,
            goldenName: "login_initial_state"
        )
    }
}

Xcode Cloud é o CI em nuvem da Apple para compilar e testar aplicativos iOS. O Xcode Cloud suporta a execução de testes XCUITest em simuladores. Os screenshot tests podem ser executados em múltiplos simuladores em paralelo (iPhone 15, iPhone 15 Pro Max, iPad Pro). Resultados: XCResult Bundle com anexos. O Xcode Cloud não está integrado ao GitHub/GitLab — use Xcode Cloud Webhooks para integração. Alternativa: GitHub Actions com macos-14 e xcodebuild.

Frameworks de comparação — iOSSnapshotTestCase (Uber) também funciona para screenshot tests se executado em um simulador. SwiftSnapshotTesting (pointfree) é mais orientado a golden tests de componentes. Para screenshot tests em iOS, use as ferramentas integradas do XCUITest + XCTAttachment + um ImageComparator personalizado (Pixelmator ou AImage). Em CI use simulador — em dispositivos reais os screenshot tests só funcionam via Device Farm (AWS Device Farm).

Processo de automação de screenshot tests em CI

Gerenciamento de baselines — as capturas de referência são armazenadas no repositório (Git LFS) ou no S3. Cada captura é nomeada conforme o modelo: {testName}_{device}_{orientation}_{locale}.png. Exemplo: loginScreenPixel7PortraitRu.png. Ao adicionar um novo dispositivo ou localidade, uma nova referência é criada. Ao alterar a UI, as referências antigas são substituídas por novas após a revisão de código. A referência faz parte da base de código, como os fontes dos testes.

Pipeline CI — (1) Compilar o aplicativo. (2) Executar screenshot tests em emuladores/simuladores. (3) Comparar capturas com referências. (4) Em caso de discrepância — gerar imagem diff. (5) Enviar artefatos diff (actual, expected, diff — três arquivos). (6) Publicar relatório HTML com tabela de resultados. (7) Se o limite for excedido — o teste falha. (8) O revisor examina os artefatos diff e toma uma decisão: aprovar (atualizar referência) ou rejeitar (corrigir código).

Limite e tolerância — a comparação absoluta pixel a pixel é muito rigorosa. Use SSIM (Índice de Similaridade Estrutural) ou MSE (Erro Quadrático Médio). SSIM 0.98 = 98% de similaridade estrutural — um bom limite. Diferentes telas podem exigir diferentes limites: tema escuro (mais preto — maior precisão), gradientes (mais ruído — menor precisão). Configure o limite por teste através do parâmetro: @ScreenshotTest(threshold = 0.99).

Device Farm vs Simulador — testes em dispositivos reais (Firebase Test Lab, AWS Device Farm) oferecem máximo realismo, mas são lentos e pagos. Testes em simuladores/emuladores são rápidos e gratuitos, mas não mostram características de dispositivos reais (GPUs diferentes, reprodução de cores da tela, densidade de pixels). Estratégia: simulador para verificação pre-merge (5 minutos), Device Farm para noturnos (30 minutos, 20 dispositivos). Na IT Sectr usamos Firebase Test Lab para execuções noturnas nos 10 principais dispositivos Android.