Testes no desenvolvimento móvel: o que é, quais tipos e como organizar

Níveis de teste: Unit, Integration, E2E

Testes unitários

Testes unitários são a base dos testes de aplicativos móveis. Eles verificam a menor unidade de código — uma única função, método ou classe de forma isolada do resto do sistema. No desenvolvimento móvel, testes unitários são escritos em JUnit (Android) e XCTest (iOS). Um bom teste unitário deve ser rápido, independente e repetível — não deve depender de rede, banco de dados ou componentes de UI. Para isolamento, são usados test doubles: mocks, stubs e fakes.

Mockito (Java/Kotlin) e MockK (Kotlin-first) são bibliotecas populares para criar objetos mock no Android. No iOS, são usados OCMock, Cuckoo ou protocolos manuais. Regra: testes unitários devem cobrir lógica de negócios e modelos de dados. Testes de UI não devem duplicar testes unitários — eles verificam a interação do usuário com a interface.

Testes de integração

Testes de integração verificam a interação entre componentes: repositório com banco de dados, ViewModel com serviço API, navegação entre telas. Ao contrário dos testes unitários, os testes de integração usam dependências reais ou próximas da realidade (por exemplo, banco de dados em memória ou servidor mock). Robolectric é um framework para executar testes Android na JVM sem emulador, acelerando testes de integração em 10x.

Testes de snapshot (Golden Tests) são um tipo especial de teste de integração que comparam um componente de UI renderizado com uma imagem de referência (snapshot). Se a aparência mudar, o teste falha — o desenvolvedor vê o que mudou. Facebook SnapshotTestCase (iOS) e Shot (Android) são ferramentas populares para testes de snapshot.

Testes E2E e de UI

Testes E2E (end-to-end) verificam o cenário completo do usuário do início ao fim: inicialização do aplicativo, login, realização de uma ação, verificação do resultado. Testes de UI são um subconjunto de E2E focado na interface. Ferramentas: Espresso (Android), XCUITest (iOS), Detox (React Native). Testes E2E são os mais lentos, por isso são executados separadamente no CI — geralmente em compilações noturnas.

Ferramentas iOS: XCTest e XCUITest

XCTest

XCTest é o framework integrado da Apple para testes unitários de aplicativos móveis. XCTestRunner executa testes no simulador ou em um dispositivo real. Testes herdam de XCTestCase, contêm setUp e tearDown para preparação e limpeza. XCTest inclui XCTAssert para asserções (XCTAssertEqual, XCTAssertNil, XCTAssertTrue) e XCTWaiter para esperar operações assíncronas.

Exemplo de um teste XCTest simples: criar um modelo User, verificar a correção da inicialização, formatação do nome e cálculo de idade. Code Coverage no Xcode mostra quais linhas de código são cobertas por testes — o objetivo para projetos comerciais: pelo menos 70–80% de cobertura da lógica de negócios. XCTest é integrado com Xcode Server e sistemas CI através de xcodebuild test.

XCUITest

XCUITest é o framework da Apple para testes de UI. Funciona através de identificadores de acessibilidade: XCUIElementQuery encontra botões, campos de entrada, tabelas por label, identifier ou tipo. XCUITest grava uma sequência de ações (record/playback) e gera código de teste. Importante: todos os elementos de UI devem ter um accessibilityIdentifier para operação estável dos testes.

Ferramentas Android: JUnit, Espresso, Robolectric

JUnit e Mockito

JUnit é o framework básico para testes unitários de aplicativos móveis em Java/Kotlin. No Android, são usados JUnit 4 (última versão estável 4.13.2) e JUnit 5 para novos projetos. Mockito é uma biblioteca para criar objetos mock: when(mock.method()).thenReturn(value) — um padrão padrão para isolar a classe testada de dependências.

Exemplo de um teste JUnit para Android:

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mock;
import org.mockito.junit.MockitoJUnitRunner;

import static org.junit.Assert.*;
import static org.mockito.Mockito.*;

@RunWith(MockitoJUnitRunner.class)
public class LoginViewModelTest {

    @Mock
    AuthRepository authRepository;

    @Test
    public void login_emptyEmail_returnsError() {
        LoginViewModel vm = new LoginViewModel(authRepository);
        String result = vm.login("", "password123");
        assertEquals("Email cannot be empty", result);
        verify(authRepository, never()).authenticate(any());
    }
}

Espresso e UI Automator

Espresso é o framework do Google para testes de UI Android. Espresso sincroniza automaticamente com a thread de UI: onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed())). Espresso é fácil de escrever e estável graças à espera integrada de estado ocioso. UI Automator é um framework para testes entre aplicativos que pode interagir com elementos do sistema (diálogos de permissão, painel de notificações).

Ferramentas multiplataforma: Detox, Appium

Detox para React Native

Detox é um framework E2E de caixa cinza para testar aplicativos móveis React Native da Wix. Detox funciona em ambas as plataformas a partir de uma única base de código de teste, usando Espresso (Android) e XCUITest (iOS) internamente. Detox espera automaticamente que o aplicativo fique ocioso (sem animações, requisições de rede, temporizadores) e só então executa a próxima ação.

Appium

Appium é um framework multiplataforma universal que suporta Android, iOS, Web e aplicativos híbridos. Appium usa o protocolo WebDriver e suporta qualquer linguagem de programação (Java, Python, JS, Ruby). Appium Server funciona como um servidor HTTP que traduz comandos em comandos nativos UI Automator / XCUITest. A principal desvantagem do Appium é a velocidade: testes executam mais lentamente que Espresso ou XCUITest nativos.

TDD e BDD: metodologias de teste

TDD: Test-Driven Development

TDD é uma metodologia de teste de aplicativos móveis onde o teste é escrito antes do código de implementação. O ciclo Red-Green-Refactor: (1) escrever um teste que falha (Red), (2) escrever o código mínimo para passar o teste (Green), (3) refatorar o código mantendo o teste aprovado. TDD fornece 100% de cobertura de teste para nova funcionalidade e arquitetura limpa, já que o teste é a primeira especificação do requisito.

BDD: Behaviour-Driven Development

BDD é uma extensão do TDD onde os testes são escritos em linguagem natural no formato Given-When-Then. Given (contexto) — When (ação) — Then (resultado esperado). Testes BDD são compreensíveis para todos os membros da equipe: desenvolvedores, testadores, analistas e clientes. Mock vs Stub vs Fake: Mock verifica interação (se o método foi chamado), Stub retorna dados fixos, Fake é uma implementação de trabalho simplificada (ex.: banco em memória). Na IT Sectr, usamos TDD para lógica de negócios crítica e BDD para cenários de aceitação.

Test Doubles é o nome geral para objetos que substituem dependências reais em testes. Há quatro tipos: Dummy (objeto para preencher parâmetros, não usado), Stub (retorna valores dados), Spy (grava chamadas para verificação), Mock (predefine chamadas esperadas). Entender a diferença é crítico para o design adequado de testes.

CI/CD e Device Farm

Automação de testes em CI/CD

CI/CD — Integração Contínua e Entrega Contínua: a prática de construir e testar automaticamente aplicativos móveis a cada mudança de código. No desenvolvimento móvel, o pipeline CI/CD inclui: linting, testes unitários, testes de integração, compilação APK/IPA e testes de UI. GitHub Actions e Bitrise são plataformas populares para CI/CD móvel. Testes devem executar rápido: testes unitários em 1–2 minutos, integração em 5–10, UI em 15–30 minutos.

Device Farm

Device Farm é uma fazenda de dispositivos reais para testes. Firebase Test Lab (Android) e Xcode Cloud (iOS) fornecem acesso em nuvem a centenas de modelos de dispositivos. Device Farm revela problemas não visíveis em emuladores: diferentes tamanhos de tela, desempenho em dispositivos antigos, problemas de compatibilidade. Na IT Sectr, usamos Firebase Test Lab para Android e Xcode Cloud para iOS regularmente.