Tecnologias

Qualidade e engenharia de contexto

nível aplicado-em-producao

Escrever teste e escrever contexto para agente de IA resolvem o mesmo problema: deixar explícito, verificável e reexecutável aquilo que só existia na cabeça de quem escreveu.

O que é prática, e o que ainda é intenção

Suíte de teste com xUnit e validação declarativa com FluentValidation são o padrão do que eu escrevo, e a maior parte dos projetos que eu toco tem os dois.

Especificação numerada versionada junto ao código e contexto de agente versionado no repositório são recentes, e ainda estão em uma minoria. Prefiro declarar onde a prática já está do que onde eu gostaria que estivesse.

Teste de integração com contêiner efêmero eu uso pouco, e em coisa recente.

Por que xUnit e FluentValidation andam juntos

Resolvem o mesmo problema em momentos diferentes. O teste prova que a regra funciona; a validação declarativa faz a regra ser legível no ponto onde ela aparece, em vez de espalhada em if pelo serviço.

Na prática isso significa teste de unidade para regra de domínio, escrito como especificação executável do comportamento, e um validador por comando rodando no pipeline antes do handler, de modo que a operação nem começa se o dado não presta. A validação devolve todos os problemas de uma vez, não o primeiro: o raciocínio por trás disso está em .

O que eu faço

  • Tratar o teste de unidade como especificação executável da regra de domínio
  • Deixar a validação declarativa e no lugar certo, para que a mensagem de erro seja do negócio e não do banco
  • Escrever especificação numerada antes de implementar, versionada junto com o código; ver Projetar antes de implementar
  • Versionar o contexto que um agente de IA precisa para trabalhar no repositório: convenção, arquitetura, o que não fazer
  • Revisar código contra padrão escrito e citável, em vez de contra opinião; ver Revisão de código e padrão
  • Registrar o atrito que custou caro, para que o próximo não pague de novo; ver Como eu depuro

Onde apliquei

Monitoramento industrial · Experiência · Pagamentos e antifraude

Suíte PMQ

O que eu ainda não fiz

Ter suíte não é ter cobertura. Quando eu digo que a maior parte do que eu toco é testada, estou dizendo que os projetos têm suíte, não que o código dentro deles esteja coberto, e essa segunda coisa eu não meço. Teste de integração com contêiner efêmero eu uso pouco, teste de contrato entre serviços eu nunca fiz, e não trabalho com mutation testing nem com teste de carga.

Pablo Mickael Quevedo Senior Software Engineer · Novo Hamburgo, RS