Mantener CI en verde cuando tu app tiene un captcha
Tu formulario de registro tiene un PopularCaptcha. Tu suite de extremo a extremo tiene que registrarse. Ahora CI está en rojo, y la solución tentadora, desactivar el captcha en la build de pruebas, significa que el flujo que pruebas no es el flujo que reciben tus usuarios.
Hay varias salidas. Se diferencian en cuánto del flujo real ejercitan, así que elige la que corresponda a la pregunta que responde tu prueba. Estas son las opciones, más o menos de la más barata a la más realista.
Scarnox resuelve PopularCaptcha hoy. Otros tipos de captcha están próximamente, así que la opción de resolución de abajo es solo para PopularCaptcha.
1. Claves de prueba para pruebas unitarias y locales
Muchos proveedores de captcha publican claves de prueba que siempre pasan. Úsalas cuando controlas el entorno y solo necesitas que el formulario se muestre y se envíe. Las claves de prueba no ejercitan una verificación real, y no ayudan cuando pruebas un entorno desplegado que usa claves reales.
2. Un bypass para tu propio staging
Algunos equipos añaden una cabecera secreta que el backend acepta en lugar de un token de captcha. Es rápido y gratuito, pero es una ruta de código que existe solo para pruebas, y a un error de configuración de existir también en producción. Si usas uno, protégelo con una comprobación del entorno, haz que el secreto sea largo y aleatorio, y prueba que se rechaza en producción.
3. Simular la llamada de verificación
Simula la petición de verificación del lado del servidor en las pruebas de integración. Es útil para comprobar la lógica de tu backend, por ejemplo qué ocurre cuando la verificación falla. No te dice nada sobre si el front end envía bien el token, así que combínalo con una de las otras opciones.
4. Resolverlo de verdad en staging y en pruebas de humo
Cuando necesitas demostrar que el flujo real funciona de extremo a extremo, con claves reales, el widget real y la verificación real, obtén un token de una API de resolución dentro de la prueba. Es la única opción que detecta una integración del widget rota.
Un helper para Playwright se ve así:
// Playwright test helper
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);
}Llámalo justo antes de enviar el formulario en la prueba, no al principio de la prueba. Los tokens caducan en unos dos minutos, y un paso lento anterior en la prueba puede consumir esa ventana.
Reduce las resoluciones al mínimo
Una suite que se registra en cada ejecución puede generar muchas resoluciones en una semana. Mantén el número bajo:
- Ejecuta la resolución real solo en staging y en una prueba de humo. Usa las otras opciones en cada commit.
- Ejecuta la resolución real una vez por pipeline, no una vez por archivo de pruebas.
- Limita las resoluciones por ejecución en tu helper. Una prueba que falla porque se alcanzó el límite es una señal clara para revisar la suite.
- Las resoluciones fallidas son gratuitas, así que un paso inestable cuesta tiempo y no dinero, pero una suite que reintenta a ciegas sigue desperdiciando minutos de runner.
Para las reglas de reintento dentro del helper, reutiliza la política de gestión de errores y backoff.
Mantén la clave fuera del repositorio
Guarda la clave como secreto de CI, con un nombre como SCARNOX_KEY, y nunca la pongas en el código de pruebas ni en los fixtures. Si se filtra, regenérala desde el panel. La clave anterior deja de funcionar de inmediato, así que una clave filtrada no puede usarse para ejecutar resoluciones durante mucho tiempo.
Usa una clave separada para CI. Si un pipeline se comporta mal, puedes rotar esa clave sin tocar nada más.
Pruébalo en tu propio staging
Crea una cuenta y empieza con crédito de prueba gratis, sin tarjeta. Conecta el helper primero a una sola prueba de humo, confirma que se registra sin errores, y solo entonces añádelo al resto de la suite. Para saber cuánto cuesta resolver a volumen, consulta los precios actuales.
Qué comprobar después del envío
Un captcha resuelto solo demuestra que el paso del widget funcionó. Después del envío, comprueba lo que importa al usuario: que carga la página siguiente, que aparece el mensaje de éxito y que la cuenta o el pedido existen en tu base de datos. Una prueba que se detiene en "sin error en el formulario" puede pasar mientras el registro falla en silencio en el backend.
Mantén las comprobaciones cerca del resultado de negocio. Verifica la URL, el mensaje visible y un registro que la prueba haya creado. Limpia ese registro al final de la ejecución para que la siguiente empiece desde un estado conocido.
Ejecutar la prueba de humo programada
Ejecuta la prueba de humo con resolución real según un calendario, por ejemplo una vez al día contra staging, en lugar de en cada pull request. Las ejecuciones programadas detectan cambios que el sitio hizo durante la noche, como una nueva versión del widget o una sitekey movida, sin gastar resoluciones en cada commit. Avisa al equipo cuando falle la ejecución programada, y deja la suite por commit con las opciones más rápidas.