Apps mobiles

Les tests mobiles UI utilisent Proxy Mail QA comme les tests webᅠ: créez une adresse de test, saisissez-la dans l’écran d’inscription de l’app, puis attendez le code ou le lien de l’e-mail. Les helpers de ces pages sont uniquement du code de test. Rien n’entre dans l’app que vous publiez.

Chaque helper fait les mêmes choses, dans son propre langageᅠ:

• Créer une adresse de test avec un mot de passe pour le formulaire, et une date de naissance, un pays ou un environnement si vous le demandez.
• Attendre le code ou le lien, y compris le lien qui ouvre l’app, et ignorer un code déjà utilisé.
• Contrôler l’e-mailᅠ: compter ce qui est arrivé (exactement un, pas deux), le contrôler (SPF, DKIM, DMARC, liens locaux ou http, destination de son lien), ou vérifier que rien n’arrive.
• Se connecter avec un compte enregistré, ou en emprunter un qu’aucun autre test n’utilise pendant les exécutions en parallèle.
• Rendre compte sur la pull requestᅠ: avec l’Action GitHub, chaque appel rejoint l’exécution du job, nommé d’après son test.

Vos tests	Guide
Maestro (iOS et Android natifs, React Native, Flutter)	Maestro
XCUITest dans Xcode (Swift)	iOS (XCUITest)
Espresso ou UI Automator dans Android Studio (Kotlin)	Android (Espresso)
Flutter integration_test (Dart)	Flutter
Detox ou Appium (JavaScript)	Detox et Appium
Un agent de codage qui pilote le iOS Simulator	Apps iOS avec un agent de codage
Un agent de codage qui pilote l’émulateur Android	Apps Android avec un agent de codage

Pour savoir quoi contrôler sur chaque plateforme (liens au démarrage à froid, App Links qui ouvrent Chrome, liens exp://, connexion par lien e-mail Firebase), consultez les guides des apps mobiles.

Gardez la clé d’API hors de l’app

Chaque guide lit la clé d’API depuis l’exécution de testᅠ: une variable d’environnement, un argument d’instrumentation ou un --dart-define. Stockez-la dans les secrets de votre CI. Ne l’ajoutez jamais à la configuration de l’app ni à Info.plist, où toute personne ayant l’app pourrait la lire.

Un --dart-define est compilé dans le build auquel il a été fourni, donc un build de test Flutter contient la clé. Ne donnez ce build à personne, que ce soit via TestFlight, Firebase App Distribution ou un storeᅠ: générez sans elle le build que vous partagez.

Ouvrir un lien de vérification ou un lien magique dans l’app

Le lien de l’e-mail est en général un lien https qui ouvre l’appᅠ: un Universal Link sur iOS, un App Link sur Android. Ouvrez-le sur l’appareil, pas dans un navigateur de bureauᅠ:

Où	Comment
XCUITest	XCUIApplication().open(url)
Espresso	startActivity avec un intent ACTION_VIEW (voir le guide)
Maestro	- openLink: ${output.link}
Detox	device.openURL({ url })
Appium	driver.execute('mobile: deepLink', { url, package }) (Android) ou { url, bundleId } (iOS)
À la main, simulateur iOS	xcrun simctl openurl booted '<link>'
À la main, émulateur Android	adb shell "am start -W -a android.intent.action.VIEW -d '<link>'"

Les liens qui utilisent le schéma propre de l’app, comme myapp://verify?token=… ou le exp://…/--/verify de Expo, sont aussi repérés et classés de la même façonᅠ: l’attente d’un lien les renvoie. Quand un e-mail contient à la fois un lien web et un lien d’app pour la même chose, le lien web passe en premierᅠ; demandez celui de l’app avec app=true (chaque helper a une option app). GET /v1/addresses/{address}/messages liste tous les liens de chaque e-mail. Proxy Mail QA n’ouvre jamais les liens, et l’app et l’extension Chrome permettent seulement de copier les liens d’app, avec les commandes du simulateur et de l’émulateur à côté dans la boîte de réception.

Codes répartis dans des cases

Beaucoup d’apps affichent une case par chiffre du code. Saisissez le code entier dans la première caseᅠ: la plupart de ces champs passent à la case suivante à chaque chiffre saisi. Si ce n’est pas le cas du vôtre, saisissez un chiffre par case. Avant de valider, vérifiez que chaque case contient son chiffreᅠ: un code partiel compte comme une tentative erronée, et beaucoup d’apps bloquent le compte au bout de quelques-unes.

Vérifier l’e-mail, pas seulement le code

Une fois le code ou le lien arrivé, contrôlez aussi l’e-mailᅠ: checkEmail avec le domaine qu’ouvrent les liens de votre app (son domaine Universal Link ou App Link) renvoie les contrôles qui échouent, et countEmails détecte un second e-mail envoyé par erreur. Chaque guide les montre dans son langage, et la REST API explique chaque contrôle.

Tester avec un serveur sur votre ordinateur

Le simulateur iOS atteint votre ordinateur à localhost. L’émulateur Android nonᅠ: il atteint votre ordinateur à 10.0.2.2. Si l’app envoie des liens de vérification vers localhost, ils ne s’ouvriront pas sur un émulateurᅠ; voir Tester des liens qui pointent vers localhost.

Les contrôles d’e-mail font échouer les liens vers localhost ou une adresse privée, car un vrai utilisateur ne pourrait pas les ouvrir. Pendant que vous testez avec votre propre ordinateur, ajoutez son hôte (comme localhost:3000 ou 10.0.2.2:3000) aux environnements de dev du projet dans Paramètres du projet, ou avec POST /v1/project/dev-hosts, et les liens vers celui-ci passent.

SMS

Proxy Mail QA ne gère que les e-mails. Les codes envoyés par SMS nécessitent un autre outil.