Teste de Jogos
Teste um jogo como um engenheiro de QA faria, usando o Claude Code ou uma sessão de chat com os arquivos do projeto.
Fluxo de Trabalho
- Leia as regras: abra o
RULES.mdse ele existir (da skill game-rules-core). Se não existir, infira as regras a partir do código e escreva-as primeiro. Regras não testáveis são bugs na especificação. - Mapeie o código: encontre o loop do jogo, máquina de estados, manipulação de entrada, colisão, spawn e código de pontuação.
- Revisão estática: examine a lista de bugs comuns em
references/checklist.md. - Escreva testes: teste unitário de lógica pura (matemática de colisão, pontuação, transições de estado) e adicione um teste de simulação determinística quando possível (semente fixa, dt fixo, entrada roteirizada).
- Execute e observe: execute os testes e, se uma ferramenta de navegador estiver disponível, jogue o jogo e capture erros do console.
- Relate: escreva
BUG_REPORT.mdusando o formato abaixo.
Categorias de teste (cubra todas)
- Loop principal: inicia, pausa, retoma, reinicia, fim de jogo, vitória. Cada transição de estado funciona e redefine as coisas certas.
- Entrada: teclas simultâneas, tecla pressionada durante pausa, toques rápidos, perda de foco (blur), toque e gamepad se suportados.
- Colisão/física: tunelamento em alta velocidade, travamento em cantos, ficar em bordas, plataformas móveis, cair para fora do mundo.
- Regras: cada linha do
RULES.mdtem pelo menos um teste: gatilho, condição, efeito, caso de borda. - Pontuação/progresso: incrementa corretamente, sem contagem dupla, reseta no reinício, persistência (localStorage) sobrevive a recarregamento e lida com dados corrompidos.
- Spawn: limites respeitados, sempre possível passar, nenhuma entidade restante após reinício, nenhum crescimento de memória ao longo do tempo.
- Independência de taxa de quadros: execute em 30, 60 e 144 FPS simulados; os resultados da jogabilidade devem corresponder.
- Desempenho: tempo de quadro, crescimento da contagem de entidades, vazamentos de memória, chamadas de desenho (3D).
- Robustez: redimensionar janela, trocar de aba, reinício rápido, viewport móvel.
- Determinismo: mesma semente mais mesmas entradas dá o mesmo resultado.
Formato do relatório de bugs
Para cada bug:
- ID / Título
- Severidade: Crítico (crash, soft-lock, perda de progresso) / Maior (regra quebrada) / Menor (visual, sensação) / Polimento
- Passos para reproduzir (numerados, exatos)
- Esperado vs Real
- Evidência: arquivo e linha, erro de console ou nome do teste com falha
- Correção sugerida (uma ou duas linhas)
Termine o relatório com uma tabela resumo (contagens por severidade) e uma lista do que NÃO foi testado.
Regras rígidas
- Nunca afirme um bug sem evidência (um teste com falha, um log ou um caminho de código que você possa apontar).
- Nunca afirme que algo funciona se você não executou; diga "revisado, não executado".
- Prefira testes determinísticos a "eu joguei e pareceu bom".
- Não altere o código do jogo a menos que solicitado; relate primeiro, corrija quando solicitado.