TDD em C#: pare de ter medo de testes e comece a escrever código que não tenha vergonha de mostrar

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

Por que "testes primeiro" não é masoquismo, mas um superpoder

\n\n

Imagine: você escreve código, tudo funciona. Você está feliz. Um mês depois, você volta ao projeto, muda uma linha — e tudo quebra. Familiar? Bem-vindo ao clube dos desenvolvedores que não escrevem testes. Agora imagine outra realidade: você altera o código, executa os testes — e em 10 segundos sabe que nada quebrou. Isso não é mágica, é TDD (Test-Driven Development) — desenvolvimento orientado a testes.

\n\n

Neste artigo, vamos analisar o TDD usando C# como exemplo. Sem teoria chata. Apenas prática, código e casos reais. Se você acha que TDD é para "arquitetos puristas" ou "monstros corporativos" — você vai se surpreender. É uma ferramenta que salvará seu código e seus nervos.

\n\n

O que é TDD e como funciona o Red-Green-Refactor

\n\n

TDD não é sobre testes. É sobre design. Você não escreve testes depois do código, mas o contrário: primeiro o teste, depois o código mínimo que o faz passar, e só então a refatoração. Esse ciclo é chamado de Red-Green-Refactor:

\n\n

Red — escrevemos um teste que certamente não passará (vermelho).
Green — escrevemos o código mínimo para o teste passar (verde).
Refactor — melhoramos o código sem alterar seu comportamento.

\n\n

Parece estranho? Vamos a um exemplo. Suponha que precisamos de uma calculadora com um método de soma. Normalmente, escrevemos a classe, depois o teste. No TDD, é o contrário.

\n\n

Passo 1: Red — escrevemos um teste que vai falhar

\n\n

using NUnit.Framework;\n\n[TestFixture]\npublic class CalculatorTests\n{\n    [Test]\n    public void Add_ShouldReturnSumOfTwoNumbers()\n    {\n        // Arrange\n        var calculator = new Calculator();\n        \n        // Act\n        var result = calculator.Add(2, 3);\n        \n        // Assert\n        Assert.AreEqual(5, result);\n    }\n}

\n\n

Executamos — o teste falha, porque a classe Calculator não existe. Vermelho é normal. Agora nossa tarefa é ficar verde.

\n\n

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

\n\n

public class Calculator\n{\n    public int Add(int a, int b)\n    {\n        return a + b; // Implementação mínima\n    }\n}

\n\n

Teste verde. Ufa. Mas o código ainda está feio. Vamos para o passo 3.

\n\n

Passo 3: Refactor — melhoramos, mas não quebramos

\n\n

Nesta etapa, podemos adicionar validações, tratamento de exceções ou alterar a arquitetura. O importante é que os testes continuem verdes.

\n\n

public class Calculator\n{\n    public int Add(int a, int b)\n    {\n        if (a < 0 || b < 0)\n            throw new ArgumentException("Only positive numbers allowed");\n        return a + b;\n    }\n}

\n\n

O teste vai falhar? Sim. Então, precisamos atualizar o teste ou alterar a lógica. No TDD, a refatoração é sempre um diálogo com os testes.

\n\n