Testes de integração no desenvolvimento mobile — o que são, tipos e como são realizados

O que são testes de integração?

Os testes de integração são uma etapa de verificação de software onde se avalia a corretude da interação entre módulos ou subsistemas individuais de um aplicativo. Enquanto os testes unitários verificam cada componente de forma isolada, os testes de integração reúnem esses componentes e verificam como eles funcionam em conjunto. Cenários típicos incluem transferência de dados entre a camada de rede e o repositório, escrita em um banco de dados via ORM e processamento de respostas de APIs de terceiros.

No contexto do desenvolvimento mobile, os testes de integração cobrem interações entre a camada de UI, a lógica de negócio e as fontes de dados. Por exemplo, um teste pode verificar que após clicar no botão “Login”, o aplicativo envia uma requisição ao servidor, recebe um token e o salva no armazenamento local. Tal verificação confirma que a cadeia de componentes funciona sem falhas.

De acordo com o World Quality Report 2023, empresas que aplicam testes de integração regularmente reduzem o número de incidentes de produção em 35% comparado a projetos que dependem apenas de testes unitários. Isso torna os testes de integração um elemento obrigatório da estratégia de garantia de qualidade no desenvolvimento comercial.

Por que os testes de integração são importantes em aplicativos móveis

Os aplicativos móveis consistem em múltiplos componentes interconectados: requisições de rede, bancos de dados locais, notificações push, serviços do sistema e SDKs de terceiros. Cada um desses componentes é desenvolvido separadamente, mas em tempo de execução eles trocam dados em tempo real. Os testes de integração detectam defeitos que não podem ser encontrados através da verificação isolada de módulos.

Entre os problemas típicos descobertos por testes de integração estão incompatibilidade de tipos de dados entre a API e o modelo do aplicativo, erros de serialização JSON, tratamento incorreto de timeouts de rede e falhas durante o acesso concorrente ao banco de dados via Room ou Core Data. Sem verificadores de integração, esses defeitos chegam à produção e só se manifestam com usuários reais.

Pesquisas do Google Testing Blog (2021) mostram que o custo de corrigir um defeito encontrado durante os testes de integração é 5 vezes menor do que após o lançamento. Isso ocorre porque nos estágios iniciais o desenvolvedor tem o contexto completo do erro e pode corrigi-lo sem um ciclo urgente de hotfix. Investir tempo na escrita de testes de integração se paga com a redução dos custos de manutenção e o aumento da confiança dos usuários.

Abordagens de testes de integração

Existem três principais abordagens para organizar testes de integração: Big Bang, Bottom-Up e Top-Down. A escolha da estratégia depende do tamanho do projeto, da arquitetura do aplicativo e da disponibilidade dos componentes no momento da escrita dos testes. Cada abordagem tem suas vantagens e limitações que são importantes de considerar ao planejar a cobertura de testes.

Big Bang

Big Bang — abordagem onde todos os componentes do sistema são conectados simultaneamente, após o que uma execução de teste geral é realizada. Este método é simples de implementar: não é necessário escrever stubs ou emular módulos individuais. No entanto, quando um erro é detectado, é difícil determinar qual componente o causou. Big Bang é justificado em projetos pequenos com arquitetura simples onde o número de módulos não excede cinco.

Bottom-Up

Bottom-Up — estratégia onde os testes de integração começam com componentes de baixo nível: banco de dados, camada de rede, serviços do sistema. Após verificar cada nível, os testes gradualmente conectam módulos de nível superior — repositórios, classes Use Case e ViewModels. A principal vantagem é a detecção precoce de defeitos nas camadas fundamentais do aplicativo, reduzindo o risco de erros em cascata em estágios posteriores do desenvolvimento.

Top-Down

Top-Down — abordagem onde os testes começam com componentes de nível superior — telas de UI e navegação, enquanto os módulos de nível inferior são simulados usando stubs ou mocks. Isso permite verificar cenários de usuário antes que o lado do servidor ou o banco de dados estejam completamente implementados. Top-Down é especialmente útil durante o desenvolvimento paralelo das partes cliente e servidor quando o backend ainda não está pronto para integração real.

Ferramentas para testes de integração

Para testes de integração de aplicativos móveis, é utilizada uma série de ferramentas especializadas, divididas em três categorias: bibliotecas para emulação de servidores, frameworks para trabalhar com bancos de dados e ferramentas de verificação de serviços do sistema. A escolha da ferramenta específica depende da plataforma — Android ou iOS — e da pilha de tecnologia do projeto.

• MockWebServer — biblioteca da Square para Android que emula um servidor HTTP em ambiente de teste. Permite definir respostas esperadas, verificar corpo e cabeçalhos das requisições, simular erros de rede.
• OHHTTPStubs — biblioteca para iOS que intercepta requisições de rede no nível NSURLProtocol e retorna respostas previamente preparadas. Suporta atrasos e erros de conexão.
• Room Testing — mecanismo embutido do Android para testar o banco de dados: criar uma instância Room em memória, realizar operações de leitura e escrita, verificar migrações e gatilhos.
• Core Data Testing — abordagem para iOS onde um contêiner Core Data em memória é criado, permitindo testar consultas, relações entre entidades e persistência de dados sem armazenamento permanente.

Exemplos de código para testes de integração

Vamos ver exemplos práticos de testes de integração para Android e iOS. Para a plataforma Android, usamos MockWebServer junto com JUnit, para iOS — XCTest com a biblioteca OHHTTPStubs. Ambos os exemplos verificam o cenário de recebimento de dados de uma API e seu armazenamento em um repositório local.

Android: Testando a camada de rede com MockWebServer

Este teste verifica que uma requisição Retrofit ao servidor emulado retorna JSON correto, e o repositório converte a resposta em um modelo de domínio. MockWebServer intercepta a requisição e retorna o JSON especificado, após o que o teste compara o resultado esperado com o real.

class UserRepositoryTest {
    private val mockServer = MockWebServer()

    @Before
    fun setup() {
        mockServer.start()
    }

    @Test
    fun fetchUser_returnsCorrectData() {
        val json = "{ \`"id\`": 1, \`"name\`": \`"Alice\`" }"
        mockServer.enqueue(MockResponse()
            .setBody(json)
            .setResponseCode(200))

        val repository = UserRepository(
            createRetrofit(mockServer.url("/").toString()))
        val user = repository.fetchUser(1)

        assertEquals(1, user.id)
        assertEquals("Alice", user.name)
    }

    @After
    fun tearDown() {
        mockServer.shutdown()
    }
}

iOS: Testando requisições de API com OHHTTPStubs

Para iOS, um teste similar usa OHHTTPStubs para interceptar requisições de URL. A biblioteca substitui a resposta do servidor no nível do framework do sistema URL Loading System, permitindo testar qualquer biblioteca de rede — URLSession, Alamofire ou Moya.

import XCTest
import OHHTTPStubs
import OHHTTPStubsSwift

class UserRepositoryTests: XCTestCase {
    func testFetchUser_returnsCorrectData() {
        stub(condition: isPath("/users/1")) { _ in
            return HTTPStubsResponse(
                jsonObject: ["id": 1, "name": "Alice"],
                statusCode: 200,
                headers: nil
            )
        }

        let repository = UserRepository()
        let expectation = expectation(description: "fetch user")

        repository.fetchUser(id: 1) { user in
            XCTAssertEqual(user.id, 1)
            XCTAssertEqual(user.name, "Alice")
            expectation.fulfill()
        }

        waitForExpectations(timeout: 2.0)
    }
}

Melhores práticas de testes de integração

Testes de integração eficazes exigem seguir um conjunto de práticas que aumentam a estabilidade dos testes e reduzem os custos de manutenção. Isole as dependências externas: use bancos de dados em memória em vez de instâncias de produção e emule APIs de terceiros usando bibliotecas de stubs. Isso elimina falhas não determinísticas causadas pela disponibilidade da rede ou estado de serviços externos.

Mantenha a independência dos testes: cada teste de integração deve funcionar de forma isolada, sem depender dos resultados de outros testes. Use as anotações @Before e @After no JUnit ou setUp e tearDown no XCTest para preparar e limpar o ambiente de teste. Isso evita a influência mútua entre testes e simplifica o diagnóstico de erros.

Cubra os casos limite: os testes de integração devem verificar não apenas os cenários de sucesso (happy path) mas também o tratamento de erros — timeouts, códigos HTTP 4xx e 5xx, respostas vazias, JSON malformado. De acordo com o Google Testing Blog (2022), 60% dos incidentes de produção estão relacionados ao tratamento incorreto de casos limite que não foram cobertos por testes.