Apps móviles
Traducido automáticamente del inglés.
Leer en inglésLas 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.
Mantén la clave de API fuera de la app
Sección titulada «Mantén la clave de API fuera de la app»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.
Códigos divididos en casillas
Sección titulada «Códigos divididos en casillas»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.
Comprueba el correo, no solo el código
Sección titulada «Comprueba el correo, no solo el código»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.
Probar contra un servidor en tu computadora
Sección titulada «Probar contra un servidor en tu computadora»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.
Mensajes de texto
Sección titulada «Mensajes de texto»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.