Introdução: por que escrevemos bugs e depois os corrigimos heroicamente?
\n\nVocê 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\nDesenvolvimento 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\nNeste 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\nO que é TDD e por que o C++ sem ele é como um carro sem freios?
\n\nTDD (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\nPor 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\nO 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
Parece simples? Sim. Mas na prática exige disciplina. Vamos tentar.
\n\nFerramentas para TDD em C++: Google Test vs Catch2
\n\nAntes 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
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\nPrática: escrevendo TDD para números de Fibonacci
\n\nVamos 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.).
Passo 1: Red — escrevemos um teste que falha
\n\nCriamos o arquivo test_fib.cpp:
#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\nTentamos compilar — obtemos um erro de linkagem. Teste RED. Perfeito!
\n\nPasso 2: Green — escrevemos o código mínimo para o teste passar
\n\nCriamos o arquivo fib.cpp:
int fibonacci(int n) {\n if (n <= 1) return n;\n return fibonacci(n - 1) + fibonacci(n - 2);\n}\n\nCompilamos 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