Mantenere verde la CI quando la tua app ha un captcha
Il tuo form di registrazione ha un PopularCaptcha. La tua suite end-to-end deve registrarsi. Ora la CI è rossa, e la soluzione allettante, disattivare il captcha nella build di test, significa che il flusso che testi non è quello che ricevono i tuoi utenti.
Ci sono diversi modi per uscirne. Differiscono per quanto del flusso reale esercitano, quindi scegli quello che corrisponde alla domanda a cui il tuo test deve rispondere. Ecco le opzioni, dalla più economica alla più realistica.
Scarnox risolve PopularCaptcha oggi. Gli altri tipi di captcha sono in arrivo, quindi l'opzione di risoluzione qui sotto vale solo per PopularCaptcha.
1. Chiavi di test per i test unitari e locali
Molti provider di captcha pubblicano chiavi di test che passano sempre. Usale quando controlli l'ambiente e ti serve solo che il form si renderizzi e si invii. Le chiavi di test non esercitano una verifica reale, e non aiutano quando testi un ambiente distribuito che usa chiavi reali.
2. Un bypass per il tuo staging
Alcuni team aggiungono un header segreto che il backend accetta al posto del token captcha. È veloce e gratuito, ma è un percorso di codice che esiste solo per i test, e a un errore di configurazione dall'esistere anche in produzione. Se lo usi, proteggilo con un controllo sull'ambiente, rendi il segreto lungo e casuale, e verifica che in produzione venga rifiutato.
3. Simula la chiamata di verifica
Sostituisci con uno stub la richiesta di verifica lato server nei test di integrazione. È utile per controllare la logica del backend, come cosa succede quando la verifica fallisce. Non ti dice nulla su se il front end invia correttamente il token, quindi abbinalo a una delle altre opzioni.
4. Risolvilo davvero in staging e nei smoke test
Quando devi dimostrare che il flusso reale funziona end-to-end, con chiavi reali, il widget reale e la verifica reale, recupera un token da un'API di risoluzione dentro il test. È l'unica opzione che intercetta un'integrazione del widget rotta.
Un helper per Playwright ha questo aspetto:
// Helper di test per 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);
}Chiamalo subito prima dell'invio del form nel test, non all'inizio del test. I token scadono in circa due minuti, e un passo lento precedente nel test può consumare quella finestra.
Riduci al minimo le risoluzioni
Una suite che si registra a ogni esecuzione può fare molte risoluzioni in una settimana. Tienine basso il numero:
- Esegui la risoluzione reale solo in staging e in un smoke test. Usa le altre opzioni a ogni commit.
- Esegui la risoluzione reale una volta per pipeline, non una volta per file di test.
- Imposta un limite di risoluzioni per esecuzione nel tuo helper. Un test che fallisce perché il limite è stato raggiunto è un segnale chiaro di rivedere la suite.
- Le risoluzioni fallite non vengono addebitate, quindi un passo instabile costa tempo e non denaro, ma una suite che riprova alla cieca spreca comunque i minuti dei runner.
Per le regole di retry dentro l'helper, riusa la politica di gestione degli errori e backoff.
Tieni la chiave fuori dal repository
Salva la chiave come segreto della CI, con un nome come SCARNOX_KEY, e non metterla mai nel codice di test o nei fixture. Se trapela, rigenerala dalla dashboard. La vecchia chiave smette di funzionare subito, quindi una chiave trapelata non può essere usata a lungo per eseguire risoluzioni.
Usa una chiave separata per la CI. Se una pipeline si comporta male, puoi ruotare quella chiave senza toccare nient'altro.
Provalo nel tuo staging
Crea un account e inizia con crediti di prova gratuiti, senza carta di credito. Collega l'helper prima a un solo smoke test, verifica che si registri correttamente, e solo dopo aggiungilo al resto della suite. Per quanto costa la risoluzione su grandi volumi, consulta i prezzi attuali.
Cosa verificare dopo l'invio
Una risoluzione riuscita dimostra solo che il passo del widget ha funzionato. Dopo l'invio, verifica ciò che conta per l'utente: la pagina successiva si carica, compare il messaggio di successo, e l'account o l'ordine esiste nel tuo database. Un test che si ferma a "nessun errore sul form" può passare mentre la registrazione fallisce silenziosamente nel backend.
Mantieni le asserzioni vicine all'esito di business. Controlla l'URL, il messaggio visibile e un record creato dal test. Elimina quel record alla fine dell'esecuzione, così la prossima parte da uno stato noto.
Eseguire lo smoke test su pianificazione
Esegui lo smoke test con risoluzione reale su una pianificazione, per esempio una volta al giorno contro lo staging, invece che a ogni pull request. Le esecuzioni pianificate intercettano le modifiche fatte dal sito durante la notte, come una nuova versione del widget o una sitekey spostata, senza spendere risoluzioni a ogni commit. Avvisa il team quando l'esecuzione pianificata fallisce, e tieni la suite per commit sulle opzioni più veloci.