SenroAI/agent-skills

Testes Senro

Gere exatamente o número de casos de teste Senro úteis solicitados pelo usuário a partir do repositório que contém a página que ele adicionou ao Senro. O agente de codificação não executa o WebMCP nem os testes gerados; o Senro executa a suíte posteriormente contra a página registrada.

Fluxo de Trabalho

1. Confirme que o repositório atual contém a página cujo comportamento WebMCP está sendo testado. Trate o repositório como a fonte da verdade.

2. Inspecione o repositório antes de gerar qualquer coisa. Exclua .git, diretórios de dependências, resultados de build, resultados de cobertura e arquivos gerados.

3. Determine como o site expõe suas ferramentas WebMCP usando o próprio código-fonte, framework, dependências, testes, fixtures e documentação do projeto. Não assuma uma API WebMCP, framework, estrutura de arquivos ou padrão de registro específico.

4. Crie um inventário interno de cada ferramenta descoberta: nome, descrição, esquema de entrada, anotações, implementação e exemplos disponíveis.

5. Pare e reporte claramente se não for possível estabelecer ferramentas WebMCP a partir do repositório. Se houver vários sites ou aplicações não relacionados, identifique-os e pergunte qual usar.

6. Leia as rotas, componentes, arquivos de dados, fixtures, código de validação, documentação e testes existentes relevantes para mapear jornadas reais de usuário e estados de sucesso e falha visíveis.

7. Leia references/import-format-v1.md antes de escrever casos de teste. Use apenas os campos e estruturas documentados lá.

8. Gere exatamente o número solicitado de casos de teste distintos. Cubra as jornadas mais fortes do repositório, incluindo fluxos bem-sucedidos, condições de contorno, entrada inválida, resultados vazios, recuperação, ações consequentes e asserções de estado visível onde a fonte as suporta.

9. Se o repositório não puder suportar o número solicitado de casos significativos e baseados na fonte, reporte a limitação e pare. Não aumente artificialmente a suíte com cenários, valores ou comportamento inventados.

10. Use apenas nomes de ferramentas e argumentos suportados pela fonte descoberta. Nunca invente IDs, contas, produtos, valores enum ou estado do backend. Use testes com apenas objetivo (goal-only) quando um valor preciso em tempo de execução não puder ser estabelecido com segurança.

11. Use chamadas de ferramenta esperadas apenas quando a fonte suportar o caminho esperado. Não force uma trajetória exata em um fluxo de trabalho onde múltiplos caminhos válidos são possíveis.

12. Crie ./senro se necessário. Escreva a suíte em ./senro/test-cases.json. Se esse arquivo já existir no disco, use o próximo sufixo numérico disponível, como ./senro/test-cases-2.json. Um arquivo rastreado pelo Git que foi deletado não é uma colisão. Mantenha as suítes diretamente em ./senro; não arquive ou mova arquivos existentes.

13. Execute o validador estrutural prévio integrado contra o arquivo exato que você gerou antes de reportar sucesso:

    node <diretório-raiz-da-skill>/scripts/validate-tests.mjs <caminho-de-saída>
    

14. Reporte o caminho de saída exato, a contagem de testes, a cobertura de jornadas e quaisquer suposições. Não afirme que um teste foi verificado em tempo de execução; o Senro deve executar a suíte contra a página ativa.

Regras de Saída

• Escreva um único objeto JSON com um array tests.
• Mantenha os nomes dos testes concisos e com menos de 70 caracteres.
• Escreva requisições de usuário naturais. Inclua detalhes técnicos apenas quando essenciais para o comportamento sendo testado.
• Onde a fonte suportar, varie modos de conversa, tipos de avaliação e complexidade da jornada. Use conversas roteirizadas para requisições explícitas e conversas simuladas para esclarecimentos ou decisões de múltiplas etapas. Não force variedade onde ela não adiciona cobertura útil.
• Atribua a testes roteirizados exatamente uma mensagem inicial de usuário.
• Atribua a testes simulados uma lista de mensagens vazia (authored message list) e nenhum acompanhamento (follow-up) criado.
• Garanta que todo teste tenha um objetivo, uma chamada esperada necessária ou uma verificação de página.
• Descreva o que o agente deve realizar em resultados bem-sucedidos. Use expectativas de chamada de ferramenta para chamadas e argumentos necessários, e verificações de página para o estado final da página. Não prescreva um caminho de implementação em um resultado quando múltiplos caminhos válidos existirem.
• Mantenha as chamadas de configuração concretas; nunca coloque operadores de correspondência nos argumentos de configuração.
• Use seletores estáveis da fonte para verificações de página.
• Afirme um estado final de página estável, não mensagens temporárias que ações posteriores possam limpar. Verifique comportamento intermediário através de verificações suportadas de chamadas de ferramenta e resultados, ou do resultado bem-sucedido.
• Use expectedCall: null quando a avaliação de chamada de ferramenta estiver desabilitada. Isso não proíbe chamadas de ferramenta.
• Não modifique o código-fonte do site enquanto gera a suíte.
• Não escreva segredos, credenciais ou dados privados de clientes na suíte.

Referências

• Formato de importação