Novo: A Integração da TestSprite com o GitHub Já Está Disponível!

Rode Testes Automaticamente a Cada Deployment no GitHub.

Conecte um repositório uma vez, e a TestSprite escuta o evento do GitHub que significa "o novo build foi implantado e a URL está no ar" — depois roda sua suíte de testes contra ela e publica o resultado de volta como um comentário no pull request ou uma verificação de commit. Sem arquivo de workflow, sem alterações no seu pipeline.

Funciona Com Qualquer Provedor Que Faz Deploy no GitHub

VercelAWS AmplifyNetlifyCI/CD auto-hospedado
A TestSprite não constrói nem implanta sua aplicação. Ela escuta o evento do GitHub que significa que o novo build está no ar, resolve a URL de destino, e roda seus testes contra ela — funcionando ao lado do seu pipeline existente em vez de substituí-lo.

Dispara a Partir da Sua CI/CD

Um deploy, uma execução de workflow, ou uma verificação de status — defina o evento de CI/CD que você já tem como o sinal que significa "pronto para testar."

Os Resultados Chegam ao PR

Sucesso/falha, passos com falha, e um link de replay são publicados como um comentário no PR ou uma verificação de commit — os revisores veem a qualidade junto com o código.

Bloqueie Merges Com uma Verificação de Status

Ative "Bloquear PR até os testes passarem" e uma verificação obrigatória impede merges enquanto houver regressões abertas.

Zero Alterações em Arquivo de Workflow

Tudo é configurado dentro da TestSprite. Seu repositório, seu .github/workflows, e seu pipeline existente permanecem intocados.

1. Seu pipeline de CI/CD constrói e faz deploy do seu aplicativo
   → produz um evento de deployment no GitHub

2. A TestSprite recebe esse evento através da
   integração GitHub App

3. A TestSprite resolve a URL de destino — a partir do
   próprio deployment, ou de um padrão de URL que você define
   (suporta {pr}, {branch}, {branch-slug}, {sha})

4. A TestSprite roda seus testes e publica os resultados
   no GitHub como um comentário no PR ou uma verificação de commit

Lance Com um Sinal em Que Você Pode Confiar

Todo deploy — uma prévia de PR ou um merge para staging — é testado contra a URL real e ativa. Não uma simulação, não um palpite.

Duas Formas de Disparar uma Execução

Pull Request

Melhor para detectar regressões antes do merge. A TestSprite testa o deployment de prévia do PR e comenta o resultado diretamente no PR.

Push para uma Branch

Melhor para testar um ambiente compartilhado como staging ou dev após cada merge. Os resultados chegam como uma verificação no commit.

Rode Ambos, Independentemente

Crie um gatilho de PR e um gatilho de push no mesmo repositório — eles rodam em seus próprios cronogramas, sem interferência.

Prompts de Correção, Prontos para Colar

Toda falha inclui um prompt de correção sugerido descrevendo a provável causa raiz — copie-o direto para o seu agente de codificação de IA.

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

Isso substitui meu workflow existente do GitHub Actions?

Não. A TestSprite escuta eventos que seu workflow já produz — um deploy, um build, uma verificação de status — e reage a eles. Ela não modifica nem substitui seu pipeline, e nenhum arquivo de workflow é adicionado ao seu repositório.

Quais permissões o GitHub App precisa?

Acesso de leitura a Actions, checks, issues e metadados; acesso de leitura e escrita a código, status de commit, deployments e pull requests. O acesso de escrita é usado apenas para publicar resultados de teste de volta como comentários no PR ou verificações de commit — a TestSprite não envia commits nem modifica arquivos de workflow.

Quais provedores de hospedagem são suportados?

Qualquer provedor que reporte um deployment ao GitHub e exponha uma URL acessível — incluindo Vercel, AWS Amplify, Netlify, e pipelines auto-hospedados que criam deployments no GitHub.

E se minhas URLs de prévia usarem um subdomínio aleatório, não o número do PR?

O campo de padrão de URL espera um padrão previsível, usando placeholders como {pr}, {branch}, {branch-slug}, e {sha}. Se seu provedor gera subdomínios imprevisíveis, configure uma URL de alias estável para o ambiente de prévia e aponte a TestSprite para ela.

O que aparece no resultado?

Uma contagem geral de sucesso/falha/bloqueado, uma pontuação de qualidade calculada sobre o subconjunto executável da suíte (casos bloqueados são reportados separadamente, já que geralmente indicam uma lacuna no ambiente de teste, e não uma regressão do produto), detalhamento completo de esperado versus observado com uma captura de tela para cada falha, e um prompt de correção pronto para copiar para o seu agente de codificação.

Dê a Cada Deploy um Teste Real, Automaticamente.

Conecte um repositório uma vez. A TestSprite cuida do resto — sem arquivo de workflow, sem alterações no seu pipeline, e um comentário ou verificação em cada PR e push.