Un mock en lugar de un código SMS real en la prueba de registro verifica el formulario, pero no el escenario completo: no detecta el retraso en la entrega, el formato inesperado del código de un servicio concreto ni un corte en el paso de ingresar el correo de confirmación. Una ejecución con un código auténtico es la única forma de comprobar que la cadena de registro funciona de punta a punta, desde la primera solicitud del número hasta el inicio de sesión en la cuenta.

Para qué sirve un escenario con un código real

Un código simulado siempre llega al instante y en el formato esperado, pero la realidad es distinta. El operador puede retrasar la entrega entre 20 y 40 segundos, el código puede llegar en dos SMS en vez de uno, y el correo de confirmación puede quedar en una cola de moderación del lado del servicio de correo. Un mock no reproduce ninguno de estos casos, y justamente son los que con más frecuencia rompen un registro en producción que llevaba meses sin tocarse.

El segundo argumento es la integración completa. Una prueba con un código real no verifica solo el análisis del SMS, sino todo el conjunto: la solicitud del número por API, la entrega del código a tu lado, la extracción del código del texto, su ingreso en el formulario y la finalización de la activación. Un corte en cualquier eslabón es un bug que conviene atrapar en CI y no en producción.

Cómo funciona la ejecución de punta a punta

El escenario se apoya en tres pasos. El primero es solicitar un número o una dirección de correo por API antes de empezar el registro en la plataforma de destino. El segundo es esperar el código: el código no llega al instante, así que el pipeline consulta el estado a intervalos fijos en lugar de esperar de una sola vez con un único timeout. El tercero es la finalización: el código se ingresa en el formulario, el registro se completa y el número o la dirección se marca como usado, para no hacer una solicitud repetida por un código que ya no va a llegar.

El timeout de espera del código se fija con margen respecto a la entrega habitual: si el código normalmente llega en 10–15 segundos, lo razonable es poner el timeout del pipeline en 60–90 segundos y no en 15. Conviene repetir la solicitud del código una sola vez, después de que venza el primer timeout: el segundo intento atrapa el retraso ocasional del operador, mientras que un tercero suele indicar un problema real en la cadena y no una fluctuación de la entrega.

Por qué es una ejecución aparte y poco frecuente, y no parte de cada commit

La prueba con un código real cuesta dinero en cada ejecución (el número o la dirección se cobra sin importar el resultado) y depende de un servicio externo cuyo retraso no controlas. Ejecutarla en cada commit significa pagar por cada push a la rama y recibir compilaciones rojas al azar, no por culpa del código, sino por el retraso externo en la entrega.

El esquema que funciona es mantener las pruebas rápidas con mock en el pipeline habitual de cada commit y sacar el escenario con código real a una ejecución aparte y poco frecuente: antes del release, una vez al día según un calendario o manualmente antes del merge a la rama principal. Así se detectan regresiones reales en la cadena de entrega sin inflar el costo ni el tiempo de la compilación normal.

Aislar los datos de prueba de los de producción

Los números y las direcciones de correo para los autotests deben salir de un pool separado y no del mismo saldo que se usa para las tareas reales: mezclarlos dificulta el control de gastos y crea el riesgo de que una ejecución de prueba se lleve por error un número reservado para un proceso real. Las cuentas creadas por la prueba conviene marcarlas con un prefijo propio o con un dominio de correo distinto y limpiarlas según un calendario; de lo contrario, los registros de prueba se acumulan en las mismas tablas que los usuarios reales y ensucian la analítica.

Control de los gastos de las ejecuciones

Cada ejecución con un código real implica el cobro por el número o la dirección de correo, más el tiempo de ejecución en el pipeline. Conviene calcular el costo de un escenario completo y multiplicarlo por la frecuencia de ejecución: una vez al día es un orden de presupuesto, y en cada commit de una rama activa es otro muy distinto, varias veces mayor y sin un aumento proporcional del beneficio. Una referencia razonable es mantener las ejecuciones poco frecuentes con códigos reales lo bastante seguidas para atrapar regresiones antes del release, pero lo bastante espaciadas para que el costo del CI no compita con el costo del servicio en sí.

Preguntas frecuentes

¿Se pueden abandonar por completo los mocks a favor de los códigos reales?

No tiene sentido: el mock es rápido, gratuito y sirve para verificar la lógica de análisis y el formulario en cada commit. El código real hace falta para un escenario de punta a punta aparte, que detecta problemas de integración y de entrega, y no para probar el código de la aplicación en cada cambio.

¿Qué hacer si el código no llegó dentro del timeout establecido?

Un reintento de la solicitud es un primer paso razonable: apaga el retraso ocasional del operador. Si el código no llega ni después del reintento, la prueba debe fallar de forma explícita y ruidosa, y no quedarse colgada hasta el timeout general del pipeline: eso ahorra tiempo de diagnóstico y señala con claridad un problema en la cadena de entrega, no una fluctuación.

¿Con qué frecuencia ejecutar la prueba con códigos reales?

Una opción práctica es una vez al día según un calendario, más una ejecución obligatoria antes del release a la rama principal. Ese ritmo detecta las regresiones en un plazo razonable y mantiene el gasto en números y direcciones predecible, sin atarlo al número de commits del desarrollo activo.

Cómo funcionan la solicitud del número y el sondeo del estado del código del lado de la API se explica en la documentación de la API. Puedes conseguir un número para la primera ejecución de prueba en la sección OTP, y el principio de sondear el estado por API es el mismo que se aplica en la rotación de IP por API. El gasto de las ejecuciones regulares es cómodo de seguir en el historial de transacciones.