Um Verificador Para o Loop, Não Mais Um Jogador Nele.
Dentro do Claude Code, Cursor, ou Codex, você não digita flags de CLI — você apenas diz: "Configure o TestSprite para este repositório e crie uma suíte de testes inicial, depois faça um smoke test do fluxo mais importante." O agente lê suas rotas e handlers, cria os testes e os executa — uma segunda passagem independente sobre seu próprio trabalho, não mais um rascunho para confiar cegamente.
Conectado a 8 Agentes de Codificação, Direto do CLI
"Configure o TestSprite para este repositório e crie uma suíte de testes inicial"
O agente lê suas rotas, handlers e fluxos-chave, cria um projeto, e redige aproximadamente 8–15 testes com asserções concretas e observáveis — criados em lote, não digitados um de cada vez.
"Verifique esta mudança com o TestSprite antes de considerá-la concluída"
Executa o teste até um veredito — passou ou falhou — em vez de parar num plano rascunhado. Escrever um teste não é a mesma coisa que executá-lo.
"Crie um teste para o caminho feliz do checkout e execute-o até um veredito"
Cobertura direcionada para um fluxo, sob demanda, com a mesma disciplina de "execute, não apenas rascunhe" da suíte completa.
Sugira o Que Você Precisa
O pacote de falha — causa raiz, captura de tela, snapshot do DOM, recomendação de correção — é um JSON estruturado, para que um agente possa analisá-lo e decidir seu próximo passo sem uma pessoa no meio.
You: "Set up TestSprite for this repo and seed a starter test suite,
then smoke-run the most important flow."
# the agent runs this on your behalf — you never type it:
$ testsprite setup
$ testsprite test create-batch starter-suite.json
✓ 11 tests created from your routes and handlers
$ testsprite test run --project prj_8f2a --ids TC_checkout,TC_login --wait
✓ TC_checkout_happy_path passed
✓ TC_login_success passed
"Rascunhado" Não É "Concluído"
Diga "execute até um veredito" e leve a sério — um plano de teste que existe mas nunca foi executado não satisfaz essa instrução. Só passou ou falhou satisfaz, e cada falha volta como um pacote estruturado sobre o qual o próprio agente pode agir.
Feito para Execuções Sem Supervisão
Lê Seu Código Primeiro
A skill de onboarding varre suas rotas, handlers e fluxos-chave antes de escrever um único teste — cobertura que começa do que seu produto realmente faz, não de um palpite.
Pontuação de Estabilidade
testsprite test flaky <testId> diz ao agente se uma falha é uma regressão real ou um teste instável, antes que ele gaste uma tentativa de correção no problema errado.
Versão Comunitária Gratuita
Oferece uma versão comunitária gratuita, tornando-nos acessíveis a todos.
Cancele no Meio da Execução
testsprite test cancel <runId> interrompe uma execução em andamento no momento em que o agente — ou você — decide que ela não é mais necessária.
Confiado por Empresas em Todo o Mundo
"TestSprite oferece geração rica de casos de teste, estrutura clara e código fácil de ler. Também suporta depuração online simples com a capacidade de expandir rapidamente gerando novos casos de teste."
"A automação do TestSprite nos ajuda a reduzir toneladas de trabalho manual. Os desenvolvedores podem facilmente detectar e resolver bugs mais cedo no processo de desenvolvimento."
FAQ
O que eu digo de fato para configurar isso?
Dentro do Claude Code, Cursor, ou outro agente suportado: "Configure o TestSprite para este repositório e crie uma suíte de testes inicial, depois faça um smoke test do fluxo mais importante." O agente cuida do resto — nenhuma flag para decorar.
O que "criar uma suíte de testes inicial" significa, na prática?
O agente lê seu código — rotas, handlers, fluxos-chave — cria um projeto TestSprite, redige aproximadamente 8–15 testes com asserções concretas e observáveis, cria-os em lote, e executa apenas os 2–3 caminhos felizes de maior valor em vez da suíte completa.
Por que o agente de codificação não pode simplesmente testar seu próprio código?
Ele pode, mas estaria corrigindo sua própria prova — seus testes herdam qualquer coisa que ele tenha entendido errado sobre os requisitos. O testsprite roda num contexto separado, controlando um navegador real ou fazendo chamadas de API reais, capturando a classe de bug que a autoavaliação estruturalmente não consegue pegar.
Como garanto que o agente não apenas rascunhe um teste e diga que terminou?
Diga "verifique esta mudança com o TestSprite antes de considerá-la concluída", ou "execute até um veredito". Essa formulação importa — um plano rascunhado mas nunca executado não satisfaz, só um passou ou falhou de verdade satisfaz.
O que o agente recebe de volta numa falha?
Um resultado JSON estruturado com um pacote completo: passo que falhou, captura de tela, snapshot do DOM, hipótese de causa raiz, recomendação de correção — tudo que ele precisa para tentar uma correção sem perguntar a uma pessoa primeiro.
Isso precisa de CI, ou funciona numa execução solo durante a noite?
Qualquer um dos dois. É o mesmo CLI, seja rodando como um passo no GitHub Actions ou dentro de uma única sessão longa de agente na sua própria máquina.