A CLI do TestSprite já está disponível — código aberto.Dê uma estrela no GitHub

Testes automatizados para GitHub, sem mais um arquivo de workflow

Seu pipeline já avisa ao GitHub quando um build foi implantado e a URL está no ar. O TestSprite escuta esse evento, executa seus testes contra o deploy e devolve o resultado como um comentário no pull request ou uma verificação no commit. A configuração leva cerca de dez minutos e não muda nada no seu repositório.
Type
Solution
Language
Português

Integra-se Perfeitamente com Seus Editores Android e com IA

Claude CodeCodexAndroid StudioVisual Studio CodeCursorTrae
Não construímos nem implantamos sua aplicação, e não modificamos seus workflows. Escutamos o evento que significa «o novo build está no ar» e testamos o que ele produziu.

Sem mudanças no repositório

O TestSprite instala-se como GitHub App e apenas lê eventos. Fica ao lado do seu pipeline, não dentro dele: nenhum YAML para escrever, nenhum workflow para manter e nada adicionado a .github/.

Disparado por um deploy real

Escolha o evento de CI/CD que dispara depois de o ambiente estar no ar. Escolher um que dispara no início do build é o erro de configuração mais comum e faz todos os testes falharem contra uma URL que ainda não existe.

Os resultados chegam ao pull request

Quantidade de testes aprovados e reprovados, uma pontuação de qualidade calculada apenas sobre o subconjunto executável, capturas do momento da falha e um prompt de correção escrito para colar direto no seu agente de programação com IA.

Uma verificação obrigatória que barra merges

Ative Block PR until tests pass e a verificação do TestSprite passa a ser obrigatória, de modo que uma regressão barra o merge em vez de entrar e ser descoberta depois.

Priority
Test
Status
HIGH
TC001_Preview_Deployment_Reachable
Pass
HIGH
TC002_Checkout_Completes_On_Preview
Failed
MEDIUM
TC003_Auth_Redirect_Preserves_Path
Pass
MEDIUM
TC004_API_Health_Returns_200
Pass
LOW
TC005_Static_Assets_Load_Without_404
Warning

Proteja cada pull request com um navegador real

Uma marca verde deveria significar que a aplicação implantada funciona, não que uma suíte foi despachada com sucesso. O TestSprite espera o veredicto real e reprova o job diante de uma execução parcial em vez de dá-la como boa.

Feito para times que publicam no GitHub

Funciona com o seu provedor

Qualquer provedor que reporte um deploy ao GitHub e exponha uma URL acessível: Vercel, AWS Amplify, Netlify e pipelines próprios que criem deploys no GitHub.

Pull request ou push

Um gatilho de pull request pega regressões antes do merge e comenta no PR. Um de push testa um ambiente compartilhado de staging ou dev após cada merge e publica uma verificação no commit. Crie os dois: eles funcionam de forma independente.

Ou conduza pela CLI

Prefere controlar a execução? A CLI de código aberto faz o mesmo a partir de qualquer CI, e testsprite ci init github gera o workflow para você.

Versão community gratuita

Oferecemos uma versão community gratuita, para que esteja ao alcance de qualquer pessoa.

Com a Confiança de Empresas do Mundo Todo

"Bom trabalho! MCP muito legal da equipe TestSprite! Para nossos aplicativos Android, a codificação com IA + testes com IA fecha o ciclo e acelera os lançamentos estáveis."

"Para Android, os testes gerados pela TestSprite são limpos e confiáveis. Os fluxos do Appium são fáceis de expandir e depurar, e as execuções agendadas mantêm nossa cobertura de dispositivos saudável."

"A automação da TestSprite reduziu drasticamente nosso QA manual de Android. Os desenvolvedores detectam e resolvem bugs móveis precocemente, mantendo nosso cronograma de lançamentos em dia."

Perguntas Frequentes

Preciso adicionar um arquivo de workflow ao meu repositório?

Não. A integração é configurada inteiramente no TestSprite e não exige nenhuma mudança no seu repositório. Se preferir conduzir a execução pelo seu próprio workflow, testsprite ci init github gera um que usa a action mantida pelo TestSprite.

Isso substitui meu workflow atual do GitHub Actions?

Não. O TestSprite escuta eventos que seu workflow já produz; ele não modifica nem substitui seu pipeline.

E se meu repositório nunca produz um deploy?

Então não há o que escutar. O TestSprite dispara a partir de um evento de deploy, então esse evento precisa existir primeiro. Adicione um passo de deploy ao pipeline, ou use a CLI dentro de um workflow e aponte o projeto para uma URL que você mesmo resolva.

Como o TestSprite sabe qual é a URL de preview?

Você define um padrão uma única vez, com marcadores resolvidos a cada execução: {pr}, {branch}, {branch-slug}, {sha} e {short-sha}. Assim https://pr-123.example.com escreve-se como https://pr-{pr}.example.com.

Quais permissões o GitHub App precisa?

Leitura em actions, checks, issues e metadata; leitura e escrita em code, commit statuses, deployments e pull requests. A permissão de escrita é o que permite publicar os resultados nos seus pull requests. O TestSprite não faz push de commits nem modifica seus arquivos de workflow.

Os resultados podem alimentar um agente de programação com IA?

Sim. Cada falha no comentário do pull request traz um prompt de correção pensado para colar em um agente. Para um ciclo mais completo, testsprite setup --agent claude instala uma skill de verificação para que o agente crie, execute e diagnostique testes sozinho.

Teste cada PR sem tocar no seu repositório