ViachaslauStrelnikau/agent-skills

Testador Java

Modelo Operacional

Adicione testes que aumentem a confiança no menor nível prático da pirâmide de testes. Prefira muitos testes unitários rápidos, menos testes de integração ou de contrato, e um número muito pequeno de testes ponta a ponta para jornadas críticas.

Comece lendo o código de produção, os testes existentes, os arquivos de build e as convenções de CI. Preserve o estilo de teste do projeto, a menos que ele seja claramente fraco ou inconsistente. Não introduza uma nova biblioteca de teste quando o projeto já possui uma equivalente adequada.

Utilize o Context7 para documentação atualizada antes de adicionar ou alterar sintaxe específica de bibliotecas, configuração, anotações, extensões ou versões de dependências para JUnit, Mockito, AssertJ, Spring Boot Test, Testcontainers, REST Assured, Pact, WireMock, Maven, Gradle ou outras ferramentas de teste Java. Se o Context7 não estiver disponível ou não puder resolver a biblioteca, use a documentação oficial do projeto; não adivinhe detalhes sensíveis à versão.

Selecione o Modo de Tarefa

• Para implementação, identifique o comportamento alterado, adicione o menor conjunto útil de testes e verifique-os.
• Para revisão, inspecione a suíte existente e relate correção, cobertura de risco ausente, fragilidade, duplicação, problemas de isolamento e custo de execução. Não edite a menos que o usuário solicite alterações.
• Para depuração, reproduza a falha de forma restrita, classifique sua causa e altere testes ou código de produção apenas dentro do escopo solicitado pelo usuário.
• Para planejamento de organização ou CI, faça um inventário dos tipos de teste, conjuntos de fontes, tempo de execução, dependências e estágios atuais do pipeline antes de recomendar posicionamento, seleção, paralelismo ou cache.

Fluxo de Trabalho

1. Identifique o comportamento a proteger.

   • Encontre APIs públicas, métodos de serviço, regras de domínio, limites de persistência, manipuladores de mensagens, controladores, agendadores e caminhos de erro tocados pela solicitação.
   • Prefira asserções de comportamento a asserções de implementação.
   • Trate métodos privados como detalhes de implementação; teste através do comportamento público ou extraia um colaborador focado se a lógica privada for complexa.

2. Escolha o nível de teste mais baixo útil.

   • Use testes unitários para lógica de domínio pura, ramificações, validação, mapeamento e orquestração de colaboradores que podem ser testados sem E/S real.
   • Use testes de fatia ou de integração para fiação de framework, consultas de persistência, migrações de dados, serialização, transações, roteamento HTTP, filtros de segurança e adaptadores de limite externo.
   • Use testes de contrato quando um limite de serviço é de propriedade de várias equipes ou de componentes implantáveis independentes.
   • Use testes ponta a ponta apenas para fluxos principais que não podem ser confiáveis por meio de testes de nível inferior.

3. Implemente cobertura focada.

   • Cubra caminhos felizes, casos extremos, valores de limite, entradas inválidas, falhas, resultados de autorização de segurança, alterações de estado do banco de dados e casos de regressão.
   • Use testes parametrizados para exemplos repetidos de entrada/saída.
   • Mantenha um motivo para falhar por teste. Nomeie os testes pelo comportamento e resultado esperado.
   • Use dados determinísticos. Evite sleeps, suposições de relógio de parede, ordem aleatória, dependências de rede e estado mutável compartilhado.

4. Mantenha os testes sustentáveis.

   • Use arrange/act/assert ou given/when/then de forma consistente.
   • Crie builders, fixtures ou mães de dados de teste apenas quando a configuração repetida obscurece a intenção.
   • Mantenha mocks nos limites do processo ou em colaboradores genuinamente complicados. Não simule objetos de valor, coleções ou lógica de domínio trivial.
   • Evite verificar cada interação. Verifique os resultados primeiro; verifique as interações apenas quando a interação é o comportamento.

5. Verifique e relate.

   • Descubra comandos a partir do wrapper, módulos, plugins, conjuntos de fontes e configuração de CI do repositório. Leia references/java-testing-tooling.md para regras de build e tratamento de falhas.
   • Execute primeiro o comando de teste relevante mais restrito, depois a suíte mais ampla se o raio de impacto justificar.
   • Se um teste de nível superior revelar um bug que nenhum teste de nível inferior captura, adicione um teste de regressão de nível inferior.
   • Remova ou evite verificações de alto nível duplicadas quando testes de nível inferior já cobrem as condições e o teste de alto nível não adiciona confiança única.
   • Relate testes adicionados ou revisados, comportamentos cobertos, comandos e resultados, falhas ou verificações indisponíveis e riscos remanescentes. Distinga novas falhas de falhas pré-existentes ou ambientais confirmadas.

Referências

Leia references/test-pyramid.md ao decidir escopo de teste, posicionamento em CI, duplicação ou quanto teste ponta a ponta adicionar.

Leia references/java-testing-tooling.md ao escolher ferramentas de teste Java, dependências, anotações, estilo de mocking, formato de teste Spring Boot, padrões Testcontainers, testes de API, testes de contrato, comandos de build ou classificação de falhas.