Ir al contenido

Las pruebas móviles de UI usan Proxy Mail QA igual que las pruebas web: crea una dirección de prueba, escríbela en la pantalla de registro de la app y espera el código o enlace del correo. Los helpers de estas páginas son solo código de prueba. Nada entra en la app que publicas.

Cada helper hace lo mismo, en su propio lenguaje:

  • Crea una dirección de prueba con una contraseña para el formulario, y una fecha de nacimiento, país o entorno si lo pides.
  • Espera el código o enlace, incluido el enlace que abre la app, y omite un código ya usado.
  • Revisa el correo: cuenta lo que llegó (exactamente uno, no dos), revísalo (SPF, DKIM, DMARC, enlaces locales o http, adónde lleva su enlace) o comprueba que no llegue nada.
  • Inicia sesión con una cuenta guardada, o toma prestada una que ninguna otra prueba tenga mientras las pruebas se ejecutan en paralelo.
  • Informa en el pull request: con la Action de GitHub, cada llamada se une a la ejecución del job, nombrada según su prueba.
Tus pruebas Guía
Maestro (iOS y Android nativos, React Native, Flutter) Maestro
XCUITest en Xcode (Swift) iOS (XCUITest)
Espresso o UI Automator en Android Studio (Kotlin) Android (Espresso)
Flutter integration_test (Dart) Flutter
Detox o Appium (JavaScript) Detox y Appium
Un agente de programación que controla el iOS Simulator Apps de iOS con un agente de programación
Un agente de programación que controla el emulador de Android Apps de Android con un agente de programación

Para saber qué revisar en cada plataforma (enlaces en arranque en frío, App Links que abren Chrome, enlaces de exp://, inicio de sesión con enlace por correo de Firebase), consulta las guías de apps móviles.

Cada guía lee la clave de API desde la ejecución de la prueba: una variable de entorno, un argumento de instrumentación o un --dart-define. Guárdala en los secretos de tu CI. Nunca la agregues a la configuración de la app ni a Info.plist, donde cualquiera con la app podría leerla.

Un --dart-define se compila dentro del build al que se le dio, así que un build de prueba de Flutter lleva la clave. No entregues ese build a nadie, ni por TestFlight, Firebase App Distribution ni una tienda: genera sin ella el que compartas.

Abrir un enlace de verificación o mágico en la app

Sección titulada «Abrir un enlace de verificación o mágico en la app»

El enlace del correo suele ser un enlace https que abre la app: un Universal Link en iOS, un App Link en Android. Ábrelo en el dispositivo, no en un navegador de escritorio:

Dónde Cómo
XCUITest XCUIApplication().open(url)
Espresso startActivity con un intent ACTION_VIEW (consulta la guía)
Maestro - openLink: ${output.link}
Detox device.openURL({ url })
Appium driver.execute('mobile: deepLink', { url, package }) (Android) o { url, bundleId } (iOS)
A mano, simulador de iOS xcrun simctl openurl booted '<link>'
A mano, emulador de Android adb shell "am start -W -a android.intent.action.VIEW -d '<link>'"

Los enlaces que usan el esquema propio de la app, como myapp://verify?token=… o el exp://…/--/verify de Expo, también se detectan y se clasifican igual: esperar un enlace los devuelve. Cuando un correo tiene un enlace web y uno de app para lo mismo, el enlace web va primero; pide el de la app con app=true (cada helper tiene una opción app). GET /v1/addresses/{address}/messages lista cada enlace de cada correo. Proxy Mail QA nunca abre enlaces, y la app y la extensión de Chrome solo te dejan copiar enlaces de app, con los comandos del simulador y del emulador junto a ellos en la bandeja de entrada.

Muchas apps muestran una casilla por cada dígito del código. Escribe el código completo en la primera casilla: la mayoría de estos campos pasan a la siguiente casilla al escribir cada dígito. Si el tuyo no lo hace, escribe un dígito en cada casilla. Antes de enviar, comprueba que cada casilla tenga su dígito: un código parcial cuenta como intento fallido, y muchas apps bloquean la cuenta tras unos pocos.

Cuando llegue el código o enlace, revisa también el correo: checkEmail con el dominio que abren los enlaces de tu app (su dominio de Universal Link o App Link) devuelve las comprobaciones que no pasa, y countEmails detecta un segundo correo enviado por error. Cada guía las muestra en su lenguaje, y la REST API explica qué significa cada comprobación.

El simulador de iOS llega a tu computadora en localhost. El emulador de Android no: llega a tu computadora en 10.0.2.2. Si la app envía enlaces de verificación a localhost, no se abrirán en un emulador; consulta Probar enlaces que apuntan a localhost.

Las comprobaciones de correo marcan como fallidos los enlaces a localhost o a una dirección privada, ya que un usuario real no podría abrirlos. Mientras pruebas contra tu propia computadora, agrega su host (como localhost:3000 o 10.0.2.2:3000) a los entornos de desarrollo del proyecto en Configuración del proyecto, o con POST /v1/project/dev-hosts, y los enlaces a él pasan.

Proxy Mail QA solo gestiona correo. Los códigos enviados por SMS necesitan otra herramienta.

¿Tienes una pregunta sobre esta página?

Pregunta en cualquier idioma. La documentación puede responderte de inmediato, o puedes enviar tu pregunta al equipo de Proxy Mail QA, que responde en inglés.