Depois de entendermos toda a teoria por trás do Desenvolvimento Guiado por Testes (se você perdeu, dá uma olhada na nossa postagem anterior sobre a teoria do TDD), chegou a hora de sujar as mãos de código.
A teoria é linda: falar de ciclo Red-Green-Refactor em slides é moleza. O bicho pega quando a gente abre a IDE, cria um projeto novo e precisa dar o primeiro passo sem colocar uma linha sequer de regra de negócio antes do teste.
Neste post (que complementa a aula prática em vídeo que gravei), vamos ver como aplicar o TDD na prática usando o Delphi e o framework DUnitX, estruturando o raciocínio por trás de uma implementação real.
Nota: O DUnitX é parte integrante nativa das versões mais recentes do RAD Studio.
🔗 https://docwiki.embarcadero.com/RADStudio/Florence/en/DUnitX_Overview
Configurando o Cenário: Do Zero ao Primeiro Teste
Muitos desenvolvedores Delphi travam no TDD porque acham que configurar testes unitários é um monstro de sete cabeças, exigindo configurações complexas de banco de dados ou frameworks externos difíceis.
Mas a regra de ouro do TDD é começar pelo mais simples. Na prática, criamos um projeto de testes (Test Project) integrado à nossa aplicação principal utilizando o DUnitX, que já vem nativo nas versões modernas do RAD Studio.
Imagine que vamos implementar uma funcionalidade simples de cálculo ou validação de regras de negócio. Antes de criar a classe principal, o que nós fazemos? Criamos o teste.
1. O Vermelho (Red): Escrevendo o teste antes do código
No DUnitX, escrevemos um método de teste anotado com [Test]. Vamos supor que queremos testar uma classe de utilitários ou regras financeiras/matemáticas (como o cálculo de um desconto ou validação de dados).
Escrevemos o teste esperando um comportamento que a nossa classe ainda nem possui:
[Test]
procedure TestarCalculoDescontoValido;
var
LCalculadora: TCalculadoraDesconto;
LValorFinal: Currency;
begin
LCalculadora := TCalculadoraDesconto.Create;
try
LValorFinal := LCalculadora.Calcular(100.00, 10); // 10% de desconto sobre 100
Assert.AreEqual(90.00, LValorFinal);
finally
LCalculadora.Free;
end;
end;
Se você tentar compilar isso agora, o Delphi vai chiar dizendo que a classe TCalculadoraDesconto ou o método Calcular não existem. E está tudo bem! O teste está vermelho (ou nem compila, o que é o nosso “Red” antecipado).
2. O Verde (Green): O mínimo necessário para passar
Agora que o teste existe e falha por falta de implementação, criamos a classe TCalculadoraDesconto e implementamos o código mais simples possível para fazer o teste passar.
Nada de arquiteturas complexas ou injeções de dependência mirabolantes neste exato segundo. O objetivo é fazer o ponteiro do DUnitX ficar verdinho:
function TCalculadoraDesconto.Calcular(AValor: Currency; APercentual: Integer): Currency;
begin
Result := AValor - (AValor * APercentual / 100);
end;
Rodamos os testes novamente. Green! O teste passou.
3. Refactor: Limpando a casa com segurança
Com o teste verde, temos a rede de segurança esticada. Se precisarmos otimizar o código, mudar o tipo de dado, extrair uma função privada ou melhorar a legibilidade, podemos fazer isso com tranquilidade. Se quebrar alguma coisa, o teste avisa na mesma hora.
Os Desafios Reais no Delphi
Quando levamos o TDD para o mundo real do Delphi, esbarramos em alguns cenários comuns:
- Acoplamento com Banco de Dados / FireDAC: É tentador querer testar uma regra que mexe direto na tabela. No entanto, o teste unitário deve ser rápido e isolado. Se o seu código depende de uma conexão física com o banco de dados rodando em outra máquina, você está criando um teste de integração disfarçado de unitário. O TDD te obriga a usar interfaces para isolar o repositório de dados.
- Mocks e Interfaces: Para testar regras que dependem de componentes visuais ou serviços externos, aprendemos a isolar comportamentos usando mocks (ou interfaces bem definidas), garantindo que o teste valide estritamente a regra de negócio.
Vídeo
Eu gravei um longo vídeo mostrando na prática complementando o vídeo O que é TDD? . Confira abaixo como ficou este novo vídeo totalmente mão na massa fazendo o TDD acontecer do absoluto Zero.
Resumo da Ópera
Praticar TDD no Delphi muda a nossa postura perante o código. Em vez de abrir o formulário (Form), jogar um monte de botões, codificar a regra no evento OnClick e depois sofrer para debugar, passamos a pensar o software em termos de unidades de comportamento.
Se você ainda não colocou o DUnitX para rodar nos seus projetos, crie um tempinho hoje mesmo, abra um projeto vazio e faça um teste simples seguindo o ciclo Red-Green-Refactor. A curva inicial exige disciplina, mas a sensação de entregar código limpo, testado e sem medo de regressão não tem preço.
E você? Já tentou aplicar testes unitários no Delphi ou costuma deixar para validar tudo na unha? Deixa aqui nos comentários a sua experiência!