DEV Community

André N. Darcie
André N. Darcie

Posted on

Agentes de IA exigem TDD: o passo a passo necessário para aplicar na prática [PT-BR]

#webdev #programming #ai #productivity

Este tutorial mostra como usar um agente de IA para praticar TDD do zero, partindo de um requisito escrito em linguagem simples até uma implementação refatorada e com testes passando.

O exemplo é um caso de uso simples/abstraido: criar conta de usuário.

O que é TDD?

TDD (Test-Driven Development) é uma técnica de desenvolvimento em três fases:

Fase O que fazer
RED Escrever os testes antes do código. Eles devem falhar.
GREEN Escrever o mínimo de código para os testes passarem.
REFACTOR Melhorar o código sem quebrar os testes.

Ameaça e defesa

Passo 1: Definir os requisitos

Antes de escrever qualquer código, escreva o que o sistema precisa fazer em linguagem simples. Use a IA para transformar isso em um documento de requisitos.

Prompt:

Crie um arquivo .md simples, listando os requisitos
necessários para criar um caso de uso de criar 
conta de usuário com nome, e-mail e senha,
apenas com o básico.
Enter fullscreen mode Exit fullscreen mode

Resultado:

# Criar Conta

## O que é isso?
Permite que uma pessoa crie uma conta na plataforma informando seu nome, e-mail e senha.

## O que o usuário precisa informar?
- Nome
- E-mail
- Senha

## Quando o cadastro é recusado?

| Situação | Motivo |
|----------|--------|
| Nome não foi preenchido | O nome é obrigatório |
| Nome tem menos de 3 letras | Nome muito curto para ser válido |
| E-mail não foi preenchido | O e-mail é obrigatório |
| E-mail está no formato errado | Precisa seguir o padrão nome@dominio.com |
| E-mail já foi usado em outro cadastro | Cada conta precisa ter um e-mail único |
| Senha tem menos de 8 caracteres | Senha muito curta |
| Senha não tem letras e números ao mesmo tempo | Senha fraca demais |

## O que acontece quando o cadastro dá certo?
A conta é criada e o sistema confirma com:
- Código único da conta
- Nome cadastrado
- E-mail cadastrado
- Data e hora do cadastro
Enter fullscreen mode Exit fullscreen mode

Dica: Antes de avançar, pergunte à IA se faltou algum edge case. Requisitos incompletos geram testes incompletos.

Outra dica: Peça para um modelo de IA diferente do que você está usando revisar os requisitos e apontar falhas graves, contradições ou cenários não cobertos. Modelos diferentes cometem erros diferentes.

Prompt:

Faltou alguma coisa importante que não considerei? Algum edge case?
Enter fullscreen mode Exit fullscreen mode

Passo 2: Visualizar o fluxo

Com os requisitos prontos, gere um fluxograma para validar o entendimento antes de escrever código.

Prompt:

Com base no arquivo .md criado, crie um fluxograma
da esquerda para a direita exemplificando o fluxo.
Enter fullscreen mode Exit fullscreen mode

Resultado:

Fluxograma do caso de uso CreateUser

Por que isso importa? O fluxograma torna visível a ordem das validações e os caminhos de erro. É mais fácil revisar um diagrama com o time do que revisar código.

Passo 3: Criar a classe sem implementação (RED)

Crie apenas o esqueleto da classe, com as dependências e a assinatura do método, sem nenhuma lógica. O método deve lançar NotImplementedException.

Prompt:

Crie a classe de Caso de Uso sem implementação alguma no método,
apenas com as dependências possíveis com base nos requisitos.
Enter fullscreen mode Exit fullscreen mode

Resultado:

public class CreateUserUseCase
{
    private readonly IUserReadRepository _readRepository;
    private readonly IUserWriteRepository _writeRepository;
    private readonly IPasswordHasher _passwordHasher;

    public CreateUserUseCase(
        IUserReadRepository readRepository,
        IUserWriteRepository writeRepository,
        IPasswordHasher passwordHasher)
    {
        _readRepository = readRepository;
        _writeRepository = writeRepository;
        _passwordHasher = passwordHasher;
    }

    public Task<Result<CreateUserResponse>> ExecuteAsync(CreateUserCommand command)
    {
        throw new NotImplementedException("Implementação pendente");
    }
}
Enter fullscreen mode Exit fullscreen mode

Passo 4: Escrever os testes (RED)

Com a classe vazia criada, peça à IA para escrever os testes baseando-se nos requisitos. Os testes devem falhar neste momento, isso é esperado e correto.

Prompt:

Com base no arquivo de requisitos e nessa classe de caso de uso,
escreva os testes unitários que validem cada requisito
e confirme que eles estão falhando.
Enter fullscreen mode Exit fullscreen mode

Resultado: testes falhando:

Testes falhando, fase RED

Antes de avançar, verifique se a cobertura está completa.

Prompt:

Esses testes estão cobrindo totalmente os requisitos
ou faltou algum caso?
Enter fullscreen mode Exit fullscreen mode

Só avance para o GREEN depois que todos os testes estiverem escritos e falhando pelo motivo certo: NotImplementedException, não erro de compilação.

Passo 5: Fechar o agente e abrir uma nova sessão

Antes de implementar, feche o agente completamente e abra uma nova conversa ou limpe o contexto do agente, por exemplo com /clean.

Na fase GREEN, a única fonte da verdade é o teste. Não o requisito, não o fluxograma, não a conversa anterior.

Passo 6: Implementar para passar nos testes (GREEN)

Na nova sessão, mostre apenas os testes e a classe vazia. O objetivo aqui é apenas fazer os testes passarem, sem se preocupar com qualidade, padrões ou boas práticas ainda.

Prompt:

Com base nos testes unitários existentes para a criação de usuário,
crie a implementação do caso de uso.
Enter fullscreen mode Exit fullscreen mode

Resultado: testes passando:

Testes passando, fase GREEN

Importante: nesta fase é normal o código ficar feio. Validações inline, strings hardcoded, acoplamentos diretos, tudo isso é esperado. O que importa é: os testes passam.

Passo 7: Identificar os problemas (REFACTOR)

Com os testes verdes, peça à IA para revisar o código com olhar crítico.

Prompt:

Liste os problemas encontrados no código implementado
com base nas boas práticas de desenvolvimento.
Enter fullscreen mode Exit fullscreen mode

Resultado:

Problemas encontrados no código

Passo 8: Refatorar (REFACTOR)

Com a lista de problemas em mãos, peça à IA para corrigi-los. Os testes são a rede de segurança: se alguma refatoração quebrar o comportamento, os testes vão acusar imediatamente.

Prompt:

Refatore esses pontos de melhoria no código.
Enter fullscreen mode Exit fullscreen mode

Resultado:

Código refatorado

Os problemas encontrados foram violações de SRP (uma classe deve ter apenas uma responsabilidade), OCP (aberto para extensão, fechado para modificação), ISP (interfaces não devem forçar dependências desnecessárias), DIP (dependa de abstrações, não de implementações concretas), DRY (não repita a mesma lógica em lugares diferentes) e um problema de segurança com salt fixo na senha.

Passo 9: Confirmar que tudo ainda passa

Após a refatoração, rode os testes novamente para garantir que nenhum comportamento foi quebrado.

Prompt:

Execute novamente todos os testes.
Enter fullscreen mode Exit fullscreen mode

Resultado: 24/24 passando:

Todos os testes passando após refatoração

Passo 10: Testar manualmente e em homologação

Com os testes automatizados passando, valide o comportamento real da feature em ambiente de homologação ou por meio de testes manuais. Ferramentas e integrações que os testes unitários não cobrem só aparecem aqui.

Se algo der errado, não tente corrigir diretamente no código. Volte ao Passo 1 e trate o bug como uma nova demanda:

Descreva o comportamento incorreto como um requisito, o que deveria acontecer e o que está acontecendo, volte para o passo 1.

Por que isso importa? Um bug corrigido sem teste pode voltar sem que ninguém perceba. O teste que comprova o bug é a garantia de que ele nunca mais vai passar despercebido.

Conclusão

O ciclo completo ficou assim:

Requisitos → Fluxograma → Esqueleto → Testes falhando
→ Fechar agente → Implementação passando → Refatoração → Testes passando
Enter fullscreen mode Exit fullscreen mode

TDD com IA significa usar o agente de IA para acelerar cada etapa do ciclo enquanto você, desenvolvedor, mantém o controle das decisões importantes: o que o sistema deve fazer, quais casos precisam ser testados e quando o código está bom o suficiente para ir para produção.

Top comments (1)

Collapse
 
diguifi profile image
Diego Penha •

Esse post tem o potencial de mudar vidas.

Muito dev está até hoje achando que codar com IA é ficar fazendo prompt e aqui vemos que vai muito além disso. É sobre reconhecer os pontos fracos de agentes e trabalhar de maneira inteligente pra mitigar seus efeitos negativos sobre o código gerado.

Abordagem simplesmente incrível. 👏👏👏