Testes E2E de aplicações C++: da teoria ao CI/CD prático

Por que "apenas testes unitários" já não são suficientes?

Você escreveu um código C++ perfeito. A compilação passou, os testes unitários estão verdes, a revisão de código foi aprovada. Você lança a versão — e uma hora depois os usuários reclamam: "o botão não funciona", "o banco de dados não responde", "a GUI trava". Familiar?

O problema é que testes unitários verificam a função, mas não verificam o cenário. Eles são isolados. Mas no mundo real, seu código C++ interage com a rede, sistema de arquivos, GPU, APIs externas e outras threads. É aqui que entram os testes E2E de aplicações C++ (End-to-End ou testes de ponta a ponta).

Neste artigo, vamos explorar como transformar o caos dos erros de integração em um sistema organizado de verificações automáticas. Você descobrirá quais ferramentas realmente funcionam, como escrever testes que não quebram na primeira execução e como integrar E2E no pipeline CI/CD. Vamos nessa!

O que são testes E2E no contexto de C++?

Testes E2E são a verificação de um cenário completo do usuário "do início ao fim". Diferente dos testes unitários, que verificam uma função isolada, o teste E2E executa sua aplicação (ou sua parte crítica) em um ambiente o mais próximo possível da produção.

Para C++, isso pode significar:

\n
• Aplicação Desktop: abrir uma janela, clicar no botão "Enviar", verificar se os dados foram para o BD.
\n
• Aplicação Servidora: enviar uma requisição HTTP para sua REST API, verificar a resposta e o estado do banco.
\n
• Embedded/Sistema: aplicar um sinal na entrada, verificar o sinal de saída após um tempo determinado.
\n

A diferença chave é o ambiente real. Nada de objetos mock para banco de dados ou rede. Apenas hardware real (ou Docker).

Ferramentas: o que realmente funciona para C++ em 2024?

Vamos direto ao ponto. Aqui está a stack que usamos na prática:

\n
• Catch2 ou Google Test — para escrever a estrutura dos testes (Arrange-Act-Assert).
\n
• Docker — para levantar um ambiente limpo (BD, filas, dependências).
\n
• Pytest + subprocess — para orquestração (sim, Python, mas é ideal para integrar binários C++).
\n
• Selenium/Appium — se você tiver uma GUI em Qt ou WebView.
\n
• CMake + CTest — para executar os testes e coletar resultados.
\n

Não tente escrever testes E2E apenas em C++. É doloroso. Use Python como cola — é mais rápido para cenários de integração.

Prática: escrevendo um teste E2E para uma REST API em C++

Suponha que temos um servidor C++ usando cpp-httplib (ou crow, ou drogon). Ele aceita requisições POST no endpoint /api/user e salva o usuário no PostgreSQL.

Vamos escrever um teste E2E que:

\n
1. Sobe um contêiner Docker com PostgreSQL.
\n
2. Compila e executa nosso servidor.
\n
3. Envia uma requisição HTTP via curl (ou cliente C++).
\n
4. Verifica se o usuário apareceu no BD.
\n

Passo 1: Docker-compose para o ambiente de teste

version: '3.8'\nservices:\n  db:\n    image: postgres:15\n    environment:\n      POSTGRES_DB: testdb\n      POSTGRES_USER: testuser\n      POSTGRES_PASSWORD: testpass\n    ports:\n      - "5432:5432"\n  app:\n    build: .\n    depends_on:\n      - db\n    ports:\n      - "8080:8080"\n    environment:\n      DB_HOST: db\n

Passo 2: Teste em C++ usando Catch2

// test_e2e_api.cpp\n#include <catch2/catch_test_macros.hpp>\n#include <httplib.h>\n#include <nlohmann/json.hpp>\n#include <cstdlib>\n\nTEST_CASE("E2E: Criar usuário via API e verificar no BD") {\n    // Arrange\n    httplib::Client cli("localhost", 8080);\n    nlohmann::json user = {\n        {"name", "John Doe"}