Mantendo o CI verde quando sua aplicação tem captcha
Seu formulário de cadastro tem um PopularCaptcha. Sua suíte de testes end-to-end precisa se cadastrar. Agora o CI está vermelho, e a solução tentadora, desligar o captcha no build de teste, faz com que o fluxo testado não seja o mesmo que os seus usuários recebem.
Há várias saídas para esse problema. Elas diferem em quanto do fluxo real exercitam, então escolha a que corresponde à pergunta que o seu teste responde. Estas são as opções, da mais barata para a mais realista.
A Scarnox resolve o PopularCaptcha hoje. Outros tipos de captcha estão em breve, então a opção de resolução abaixo vale apenas para o PopularCaptcha.
1. Chaves de teste para testes unitários e locais
Muitos provedores de captcha publicam chaves de teste que sempre passam. Use-as quando você controla o ambiente e só precisa que o formulário seja renderizado e enviado. Chaves de teste não exercitam a verificação real e não ajudam quando você testa um ambiente publicado que usa chaves reais.
2. Um bypass para o seu staging
Algumas equipes adicionam um cabeçalho secreto que o backend aceita no lugar de um token de captcha. É rápido e gratuito, mas é um caminho de código que existe só para testes, e a um erro de configuração de existir em produção. Se você usar um, proteja-o com uma verificação de ambiente, torne o segredo longo e aleatório e teste se ele é rejeitado em produção.
3. Simule a chamada de verificação
Substitua a requisição de verificação do lado do servidor nos testes de integração. Isso é bom para verificar a lógica do backend, como o que acontece quando a verificação falha. Mas não diz nada sobre o front end enviar o token corretamente, então combine com uma das outras opções.
4. Resolva de verdade no staging e nos smoke tests
Quando você precisa provar que o fluxo real funciona de ponta a ponta, com chaves reais, o widget real e a verificação real, busque um token em uma API de resolução dentro do teste. Essa é a única opção que pega uma integração de widget quebrada.
Um helper para Playwright fica assim:
// Helper de teste do Playwright
export async function solveCaptcha(page) {
const sitekey = await page.getAttribute("[data-sitekey]", "data-sitekey");
const r = await fetch("https://api.scarnox.com/api/tasks/create", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.SCARNOX_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
captcha_type: "PopularCaptchaTaskProxyless",
site_key: sitekey,
site_url: page.url(),
}),
});
const { errorId, solution, errorCode, errorDescription } = await r.json();
if (errorId !== 0) throw new Error(`${errorCode}: ${errorDescription}`);
await page.evaluate((t) => {
document.querySelectorAll('[name="h-captcha-response"],[name="g-recaptcha-response"]')
.forEach((el) => { el.value = t; });
}, solution.token);
}Chame-o logo antes do envio do formulário no teste, não no início do teste. Os tokens expiram em cerca de dois minutos, e uma etapa lenta anterior no teste pode consumir essa janela.
Mantenha as resoluções no mínimo
Uma suíte que faz cadastro em toda execução pode gerar muitas resoluções em uma semana. Mantenha o número baixo:
- Rode a resolução real apenas no staging e em um smoke test. Use as outras opções em todo commit.
- Rode a resolução real uma vez por pipeline, não uma vez por arquivo de teste.
- Limite as resoluções por execução no seu helper. Um teste que falha porque o limite foi atingido é um sinal claro para revisar a suíte.
- Resoluções com falha não são cobradas, então uma etapa instável custa tempo, não dinheiro, mas uma suíte que tenta de novo às cegas ainda desperdiça minutos de runner.
Para as regras de retentativa dentro do helper, reaproveite a política de tratamento de erros e backoff.
Mantenha a chave fora do repositório
Guarde a chave como um segredo do CI, com um nome como SCARNOX_KEY, e nunca a coloque no código de teste ou nos fixtures. Se ela vazar, gere uma nova no painel. A chave antiga para de funcionar imediatamente, então uma chave vazada não pode ser usada por muito tempo para rodar resoluções.
Use uma chave separada para o CI. Se um pipeline se comportar mal, você pode rotacionar essa chave sem mexer em nada mais.
Teste no seu próprio staging
Crie uma conta e comece com crédito de teste grátis, sem cartão. Conecte o helper em um smoke test primeiro, confirme que ele faz o cadastro sem problemas e só então adicione-o ao resto da suíte. Para saber quanto custa a resolução em volume, veja os preços atuais.
O que verificar após o envio
Um captcha resolvido só prova que a etapa do widget funcionou. Depois do envio, verifique o que importa para o usuário: a próxima página carrega, a mensagem de sucesso aparece e a conta ou o pedido existe no seu banco de dados. Um teste que para em "nenhum erro no formulário" pode passar enquanto o cadastro falha silenciosamente no backend.
Mantenha as verificações próximas do resultado de negócio. Confira a URL, a mensagem visível e um registro que o teste criou. Apague esse registro no fim da execução, para que a próxima comece de um estado conhecido.
Rodando o smoke test em agenda
Rode o smoke test com resolução real em uma agenda, por exemplo uma vez por dia no staging, em vez de em cada pull request. Execuções agendadas detectam mudanças que o site fez durante a noite, como uma nova versão do widget ou um sitekey alterado, sem gastar resoluções em cada commit. Avise a equipe quando a execução agendada falhar e mantenha a suíte por commit nas opções mais rápidas.