TDD em C++: Desenvolvimento Orientado a Testes para Gênios Preguiçosos

Treinador Online de Python para Iniciantes

Aprenda Python facilmente sem sobrecarga teórica. Resolva tarefas práticas com verificação automática e escreva código diretamente no navegador.

Start Course

Introdução: por que escrevemos bugs e depois os corrigimos heroicamente?

\n\n

Você já escreveu um código que funcionava "mais ou menos bem" e, três dias depois, encontrou um bug que quebrava tudo? Se sim — bem-vindo ao clube. Se não — ou você é um deus do C++, ou simplesmente ainda não colocou nada em produção.

\n\n

Desenvolvimento Orientado a Testes (TDD) não é uma dieta da moda para programadores. É uma disciplina que vira o processo de escrever código de cabeça para baixo. Em vez de primeiro escrever a lógica e depois desesperadamente pensar em como testá-la, fazemos o oposto: primeiro o teste, depois o código. Parece loucura? Talvez. Mas é assim que nasce um código que não envergonha você na frente dos colegas e não quebra numa sexta-feira à noite.

\n\n

Neste artigo, vamos explorar o TDD em C++ com exemplos reais: escreveremos uma biblioteca simples para trabalhar com números de Fibonacci, usando o ciclo Red-Green-Refactor. Você verá como o TDD ajuda não apenas a evitar bugs, mas também a projetar interfaces.

\n\n

O que é TDD e por que o C++ sem ele é como um carro sem freios?

\n\n

TDD (Test-Driven Development) é uma metodologia de desenvolvimento onde primeiro se escreve um teste que deliberadamente falha (Red), depois se escreve o código mínimo para fazer o teste passar (Green) e, finalmente, realiza-se a refatoração (Refactor) para melhorar a estrutura sem alterar o comportamento.

\n\n

Por que isso é importante especialmente para C++? Porque C++ é uma linguagem onde é fácil dar um tiro no pé: comportamento indefinido, vazamentos de memória, conversões de tipo incorretas. O TDD cria automaticamente uma rede de segurança que captura erros em tempo de compilação e execução.

\n\n

O ciclo Red-Green-Refactor: como funciona

\n\n
    \n
  • Red: escrevemos um teste que deve falhar. Este é o nosso "requisito" para o código.
  • \n
  • Green: escrevemos o código mínimo para o teste passar. Nada de superengenharia!
  • \n
  • Refactor: melhoramos o código (removemos duplicação, simplificamos a lógica) — os testes permanecem verdes.
  • \n
\n\n

Parece simples? Sim. Mas na prática exige disciplina. Vamos tentar.

\n\n

Ferramentas para TDD em C++: Google Test vs Catch2

\n\n

Antes de escrever código, vamos escolher um framework de teste. Dois candidatos principais:

\n\n
    \n
  • Google Test — poderoso, popular, com muitos macros. Ótimo para projetos grandes.
  • \n
  • Catch2 — leve, moderno, com sintaxe conveniente. Ideal para exemplos didáticos e microsserviços.
  • \n
\n\n

Neste artigo, usaremos o Catch2 (v3), porque é minimalista e não requer configurações extras. Mas se você prefere o Google Test — os princípios do TDD são os mesmos.

\n\n

Prática: escrevendo TDD para números de Fibonacci

\n\n

Vamos imaginar que precisamos escrever uma função fibonacci(int n) que retorna o n-ésimo número de Fibonacci (0-ésimo = 0, 1-ésimo = 1, 2-ésimo = 1, 3-ésimo = 2, etc.).

\n\n

Passo 1: Red — escrevemos um teste que falha

\n\n

Criamos o arquivo test_fib.cpp:

\n\n
#define CATCH_CONFIG_MAIN\n#include <catch2/catch_test_macros.hpp>\n\n// A função ainda não foi declarada — isso é normal\nint fibonacci(int n);\n\nTEST_CASE("Números de Fibonacci", "[fib]") {\n    REQUIRE(fibonacci(0) == 0);\n    REQUIRE(fibonacci(1) == 1);\n    REQUIRE(fibonacci(2) == 1);\n    REQUIRE(fibonacci(10) == 55);\n}
\n\n

Tentamos compilar — obtemos um erro de linkagem. Teste RED. Perfeito!

\n\n

Passo 2: Green — escrevemos o código mínimo para o teste passar

\n\n

Criamos o arquivo fib.cpp:

\n\n
int fibonacci(int n) {\n    if (n <= 1) return n;\n    return fibonacci(n - 1) + fibonacci(n - 2);\n}
\n\n

Compilamos e executamos os testes. Eles passam? Sim, mas isso não é eficiente. No entanto, nosso objetivo é Green, não a perfeição. Por enquanto, deixamos como está.

\n\n

Passo 3: Refactor —

Blogs

Book Recommendations