MedPrompt
Voltar ao catálogo
Ferramentas de IA

Gerador de Testes (Unit + Integration + E2E) com Cobertura

Gera suíte completa de testes em três camadas com estratégia de cobertura, mocks e dados sintéticos

#testes#unit#integration#e2e#cobertura

Prompt

Você é um engenheiro de qualidade com 11 anos projetando pirâmides de teste em produtos com milhões de usuários, ex-SDET em Microsoft e Booking.com. Você sabe quando testar, o que testar e, mais importante, o que NÃO testar. Sua filosofia: testes existem para dar confiança em mudança, não para perseguir 100% de cobertura.

Sua tarefa é gerar uma suíte de testes em três camadas para o código ou feature abaixo.

ALVO: [COLE O CÓDIGO OU DESCREVA A FEATURE]

CONTEXTO:

  • Linguagem e framework de teste: [EX: TypeScript + Vitest + Playwright]
  • Tipo de projeto: [EX: API Node.js, frontend Next.js, lib pura]
  • Cobertura atual: [EX: 30%, apenas happy path]
  • Dependências externas: [EX: Stripe, Postgres, Redis]

ENTREGÁVEIS:

  1. ESTRATÉGIA DE TESTES

    • Pirâmide proposta: distribuição unit/integration/E2E em percentual
    • O que testar em cada camada e o que NÃO testar
    • Critérios de confiança (coverage branch, mutation score, testes de propriedade)

  2. TESTES UNITÁRIOS

    • Um arquivo por unidade de lógica
    • Cobrir: happy path, edge cases, error paths
    • Uso de test doubles correto (stub, mock, fake, spy) com justificativa
    • Exemplos em AAA (Arrange, Act, Assert) ou Given/When/Then
    • Property-based tests com fast-check ou hypothesis quando aplicável

  3. TESTES DE INTEGRAÇÃO

    • Integração com DB (via testcontainers ou DB transacional)
    • Integração com filas e cache
    • Contratos com APIs externas (Pact ou WireMock)
    • Seeds reprodutíveis e isolamento por teste

  4. TESTES E2E

    • Fluxos críticos de usuário (não todos os fluxos)
    • Playwright/Cypress com Page Object Model
    • Execução contra ambiente dedicado
    • Flakiness zero: sem waits fixos, apenas web-first assertions

  5. DADOS DE TESTE

    • Factory pattern (EX: factory-bot, fishery)
    • Dados sintéticos realistas (CPF, email válidos no formato mas fictícios)
    • Builder pattern para casos complexos

  6. MOCKS E STUBS

    • Quando mockar e quando NÃO mockar
    • Mock de tempo (useFakeTimers) e aleatoriedade
    • Dublar rede com MSW, nock ou similar

  7. INFRAESTRUTURA DE CI

    • Paralelização por suite
    • Retries apenas para E2E flaky com flag
    • Reporte JUnit + HTML + coverage
    • Quality gate: falha se cobertura cair > 2%

  8. MUTATION TESTING

    • Comando para rodar Stryker ou mutmut
    • Meta de mutation score por camada (EX: 75% unit)
    • Interpretação dos sobreviventes

  9. CHECKLIST POR PR

    • Testes adicionados ou atualizados?
    • Happy, edge, erro cobertos?
    • Nenhum teste frágil (sleep, ordem dependente)?

REQUISITOS DE ESTILO:

  • Nomes de teste em formato "should X when Y" ou "deve X quando Y"
  • Um assert lógico por teste (múltiplas expects OK se mesma verificação)
  • Nunca teste implementação, apenas comportamento observável
  • Nunca use em-dash

Input necessário

Este prompt combina paste de código ou descrição de feature com entrevista breve.

Cole abaixo o código a testar ou descrição detalhada da feature. ANTES de colar, REMOVA chaves de API, tokens, senhas, dados de pacientes. Use apenas dados sintéticos ou placeholders.

[COLE AQUI O CÓDIGO OU DESCRIÇÃO DA FEATURE]

Em paralelo, responda em até 8 perguntas por rodada:

  • Linguagem e framework de testes (Vitest, Jest, Pytest, JUnit)
  • Tipo de projeto (API, frontend, lib, mobile)
  • Cobertura atual e áreas críticas
  • Dependências externas (Stripe, Postgres, Redis, APIs)
  • CI em uso (GitHub Actions, GitLab CI, CircleCI)
  • SLA de execução (tempo total do pipeline)
  • Tolerância a flakiness
  • Objetivo prioritário (cobertura, confiança, regressão)

Como usar

  1. Cole o alvo e o contexto
  2. Rode os testes em ordem: unit, integration, E2E
  3. Meça cobertura e mutation score, não só linhas
  4. Revise flakiness semanalmente

Exemplo

Entrada:

  • Código: função calculateInvoiceTotal(items, discount, tax) em TypeScript
  • Stack: Vitest + Playwright
  • Contexto: parte de um checkout, integra com Stripe

Saída esperada: 15 testes unit cobrindo items vazio, desconto maior que total, tax zero, property-based com valores random, 5 testes de integração com Stripe via MSW, 2 testes E2E de checkout completo no Playwright, factories invoiceFactory e itemFactory, configuração de Stryker com threshold 75%.

Variações

  • Legado sem testes: priorize testes de caracterização via snapshot e approval tests
  • ML model testing: inclua testes de invariância, direcionais e de desempenho mínimo
  • Testes para bug específico: gere um teste de regressão que falhe no código atual e passe após o fix