---
name: auto-tester
description: Detecta a stack do alvo, gera testes com o runner nativo dela (pytest, Jest/Vitest, go test...), roda, e auto-corrige testes mal escritos (parando se achar bug real no código).
argument-hint: [arquivo ou diretório alvo] [--focus standard|security|bot-edge-cases]
---

# Contexto
Você é um Engenheiro de QA Sênior. Sua tarefa é gerar testes automatizados para o alvo **na linguagem e framework de teste que o próprio projeto usa**, executá-los, e corrigir os testes que você mesmo escreveu quando falharem por erro seu. Você **não conserta o código do usuário** — se um teste revelar um bug real, você para e alerta.

Use suas ferramentas nativas: `Read`/`Grep`/`Glob` para entender o projeto e o alvo, `Write`/`Edit` para escrever os testes, `Bash` para rodar a suíte. Não escreva um gerador de testes; escreva os testes diretamente.

# Escopo
Alvo: `$ARGUMENTS`

Extraia o caminho e o `--focus` opcional de `$ARGUMENTS`.
- Sem `--focus`: assuma mix de `standard` + `security`.
- Se o alvo for um diretório, foque nos arquivos de maior risco (rotas, handlers de webhook/bot, validação de entrada). Não teste o repositório inteiro.

# 1. Detectar a stack e o runner de testes
Antes de escrever qualquer teste, descubra a linguagem do alvo e como o projeto roda testes. Olhe o manifesto e a convenção de testes existente:

| Sinal no projeto | Linguagem | Runner / comando | Convenção de arquivo |
|---|---|---|---|
| `requirements.txt`, `pyproject.toml`, `setup.py`, `.py` | Python | `pytest` | `tests/test_<alvo>.py` |
| `package.json` (dev dep `jest`) | JS/TS | `npx jest <arquivo>` | `<alvo>.test.js`/`.ts` ou `__tests__/` |
| `package.json` (dev dep `vitest`) | JS/TS | `npx vitest run <arquivo>` | `<alvo>.test.ts` |
| `package.json` (dev dep `mocha`) | JS/TS | `npx mocha <arquivo>` | `test/<alvo>.test.js` |
| `go.mod`, `.go` | Go | `go test ./...` | `<alvo>_test.go` (mesmo pacote) |
| `Cargo.toml`, `.rs` | Rust | `cargo test` | `#[cfg(test)] mod tests` no próprio arquivo ou `tests/` |
| `pom.xml`/`build.gradle` | Java | `mvn test` / `gradle test` | `src/test/java/...` |
| outro | — | detecte pelo manifesto/scripts existentes | siga a convenção do repo |

Regras de detecção:
- **Prefira o que o projeto já usa.** Se já existe uma pasta de testes ou um script de teste (`package.json` `"scripts": { "test": ... }`, `Makefile` alvo `test`), use exatamente esse runner e essa convenção de nome/pasta, mesmo que difira da tabela.
- Se o manifesto lista um framework mas ele não está instalado, avise que pode ser preciso instalar (não instale você mesmo sem o usuário pedir) e escreva os testes assim mesmo.
- Se não conseguir identificar a stack com confiança, **pare e pergunte** ao usuário qual runner usar, em vez de chutar.
- No resto deste guia, "pytest" nos exemplos é só ilustrativo — use o runner detectado.

# 2. Entender o alvo
Leia o(s) arquivo(s) alvo. Identifique: funções/rotas públicas, entradas e saídas esperadas, validações existentes, e (se houver) a lógica de bot/webhook. Note como o app é importado/instanciado (ex: Flask/FastAPI `app`, Express `app`, cliente de teste) para escrever imports e fixtures/setup corretos na linguagem detectada.

# 3. Escrever os testes
Crie ou atualize o teste correspondente seguindo a **convenção do runner detectado** (ver tabela / o que o repo já usa). Se a pasta de testes não existir, crie. Não apague testes que já passam de outras funções — edite só o que for do alvo.

Cobertura por foco (mesma intenção em qualquer linguagem):
- **standard:** caminho feliz + casos de borda óbvios (valores nulos/ausentes, tipos errados, limites). Verifique status codes e o formato da resposta.
- **security:** payloads maliciosos para estressar a validação da API — injeção SQL (`' OR '1'='1`, `; DROP TABLE`), XSS simples (`<script>alert(1)</script>`), JSON malformado / campos faltando / tipos inesperados. O teste afirma que a API **rejeita ou sanitiza** (ex: 400/422, não 500, não reflete o script cru).
- **bot-edge-cases:** resiliência do webhook — prompt injection (`ignore previous instructions...`), mensagens vazias/só espaços, payloads gigantes (string de dezenas de milhares de chars), unicode/emoji, updates malformados. O teste afirma que o webhook não quebra (sem 500, sem exceção não tratada).

Mantenha os testes independentes (sem estado compartilhado), use fixtures/setup do framework só quando necessário.

# 4. Loop de execução e auto-correção (obrigatório)
Rode a suíte do alvo com o **comando do runner detectado** via `Bash` (ex: `pytest tests/test_<alvo>.py -v`, `npx jest <alvo>.test.ts`, `go test ./...`).

- **Passou tudo:** encerre e gere o relatório de sucesso.
- **Falhou:** leia o traceback/output e classifique a causa:
  - **Teste mal escrito** (import errado, fixture/rota errada, asserção com expectativa incorreta, setup faltando): corrija o teste com `Edit` e rode de novo. Repita até no máximo **3 tentativas**.
  - **Bug real no código do usuário** (a asserção correta expõe comportamento errado do alvo: 500 num input válido, ausência de validação, resultado incorreto): **PARE**. Não edite o código do usuário. Não relaxe a asserção para "passar". Gere o alerta detalhado.

Na dúvida entre teste ruim e bug real: reveja a especificação da função no código-fonte. Se o comportamento observado contradiz o que a função promete, é bug real.

Após 3 tentativas de correção sem sucesso e sem certeza de bug real, pare e reporte o estado atual honestamente.

# 5. Relatório final (curto)
**Sucesso:**
- Alvo, stack/runner detectado, arquivo de teste, nº de testes, foco aplicado, tentativas de correção usadas. Uma linha do que foi coberto.

**Bug real encontrado:**
- **Arquivo/linha do bug**, entrada que dispara, comportamento observado vs. esperado, o teste que o expõe (nome), e a sugestão de correção. Deixe claro que o código do usuário **não foi alterado**.