Tests d'applications mobiles : émulateurs, simulateurs et appareils réels

Vous venez de terminer votre application mobile. Elle fonctionne parfaitement sur votre ordinateur, le build est signé et prêt. Vous êtes confiant pour la soumettre sur le store. Mais voici la vérité qui dérange : votre machine de développement n'est pas le téléphone de vos utilisateurs. Loin de là.

Les utilisateurs exécutent votre application sur des centaines d'appareils différents. Tailles d'écran variées, versions d'OS, niveaux de batterie, conditions réseau et configurations matérielles hétérogènes. Un bug qui ne se manifeste jamais sur votre machine de développement peut faire planter l'application sur un modèle de téléphone spécifique. Une seule mauvaise version peut faire chuter votre note sur le store et vous faire perdre des utilisateurs du jour au lendemain.

Tester les applications mobiles n'est pas optionnel. Mais la manière dont vous testez, et l'environnement d'exécution de ces tests, fait une énorme différence dans le niveau de confiance que vous obtenez avant la mise en production.

Les couches de test qui comptent

Le test mobile n'est pas une activité monolithique. C'est un empilement de couches, chacune détectant différents types de problèmes à des vitesses différentes.

Les tests unitaires se situent à la base. Ils vérifient qu'un comportement spécifique fonctionne correctement. En mobile, cela signifie tester depuis un point d'entrée pertinent : le ViewModel réagit-il correctement lorsque l'utilisateur appuie sur un bouton ? Le cas d'utilisation retourne-t-il le bon résultat pour une entrée donnée ? Vous ne testez pas les détails d'implémentation internes. Vous testez le comportement observable. Les tests unitaires sont rapides, souvent de l'ordre de la milliseconde. Vous pouvez les déclencher à chaque modification de code dans votre pipeline en utilisant un émulateur ou un simulateur. Aucun appareil physique n'est nécessaire.

Les tests d'intégration se situent un niveau au-dessus. Ils vérifient comment les composants fonctionnent ensemble. Les données provenant de l'API s'affichent-elles correctement à l'écran ? Le stockage local fonctionne-t-il après la connexion de l'utilisateur ? Ces tests nécessitent un environnement qui ressemble à un appareil réel. Les émulateurs, simulateurs ou appareils physiques conviennent tous, selon ce que vous intégrez.

Les tests d'interface utilisateur (UI) se situent au sommet. Ils simulent des interactions utilisateur réelles : appuyer sur des boutons, remplir des formulaires, faire défiler des listes et vérifier que les éléments attendus apparaissent à l'écran. Ces tests sont les plus proches de ce que vos utilisateurs vivent réellement. Ils sont également les plus lents et les plus fragiles. Un petit changement de mise en page peut les casser. Mais lorsqu'ils réussissent, vous savez que l'application fonctionne du point de vue de l'utilisateur.

Chaque couche a sa place. Les tests unitaires offrent un retour rapide. Les tests d'intégration détectent les problèmes de câblage. Les tests UI valident l'expérience. Vous avez besoin des trois, mais vous n'avez pas besoin de tous les exécuter à chaque déclenchement.

Émulateurs et simulateurs : rapides mais imparfaits

Les émulateurs (Android) et les simulateurs (iOS) sont les chevaux de bataille des tests mobiles. Ils sont gratuits, faciles à déployer dans un pipeline CI/CD et suffisants pour la plupart des vérifications logicielles et de mise en page.

Vous pouvez y exécuter des tests unitaires, des tests d'intégration et même des tests UI. Ils démarrent rapidement, prennent en charge différentes versions d'OS et permettent de simuler diverses tailles d'écran. Pour le développement quotidien et les builds internes, ils sont généralement suffisants.

Mais ils ont un angle mort. Les émulateurs et simulateurs ne reproduisent pas le comportement réel d'un appareil. Les performances sont différentes. La consommation de la batterie est différente. Les réponses des capteurs sont différentes. Le comportement réseau sur la cellule est différent. Un test qui réussit parfaitement sur un émulateur peut échouer sur un appareil physique en raison de problèmes de timing, de pression mémoire ou de particularités matérielles.

Pour rendre cela concret, voici un job GitHub Actions qui crée un émulateur Android, attend son démarrage, exécute des tests instrumentés et collecte les résultats :

name: Android Instrumented Tests

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'

      - name: Create and start emulator
        run: |
          echo "no" | avdmanager create avd -n testDevice -k "system-images;android-33;google_apis;x86_64" --force
          $ANDROID_HOME/emulator/emulator -avd testDevice -no-window -no-audio &

      - name: Wait for emulator to boot
        run: |
          adb wait-for-device
          adb shell settings put global window_animation_scale 0.0
          adb shell settings put global transition_animation_scale 0.0
          adb shell settings put global animator_duration_scale 0.0

      - name: Run instrumented tests
        run: ./gradlew connectedCheck

      - name: Upload test results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: app/build/reports/androidTests/connected/

Si vous ne testez que sur des émulateurs, vous livrez avec des informations partielles.

Fermes de devices : du matériel réel à l'échelle

C'est là qu'interviennent les fermes de devices. Une ferme de devices est un service qui vous donne accès à de vrais téléphones et tablettes situés dans un centre de données. Vous téléchargez votre application, exécutez vos tests sur des dizaines d'appareils simultanément et obtenez un rapport indiquant ce qui a réussi et ce qui a échoué sur chaque appareil.

Les options populaires incluent Firebase Test Lab pour Android et iOS, et AWS Device Farm. Ces services prennent en charge différents modèles d'appareils, versions d'OS et tailles d'écran. Vous pouvez les intégrer directement dans votre pipeline CI/CD. Chaque fois qu'un build est terminé, le pipeline déclenche des tests sur du matériel réel avant que l'application n'atteigne le store.

Les fermes de devices détectent les problèmes que les émulateurs manquent. Les crashes sur du matériel spécifique, les problèmes de mise en page sur des ratios d'écran inhabituels, la dégradation des performances sur les appareils plus anciens. Elles fournissent également des captures d'écran et des journaux de chaque exécution de test, ce qui facilite le diagnostic des échecs.

Mais les fermes de devices ne sont pas gratuites. Elles coûtent de l'argent par exécution de test, et les tests prennent plus de temps que les tests sur émulateur. Vous ne voulez pas exécuter chaque build sur une ferme de devices. Ce serait lent et coûteux.

Quand utiliser quoi

La décision est pratique, pas idéologique. Utilisez les émulateurs et simulateurs pour un retour rapide pendant le développement et pour les builds internes. Utilisez les fermes de devices de manière stratégique avant les versions.

Le diagramme suivant résume l'environnement recommandé pour chaque type de test en fonction des besoins de rapidité et de fidélité :

flowchart TD A[Type de test] --> B{Test unitaire ?} B -->|Oui| C[Émulateur / Simulateur] B -->|Non| D{Test d'intégration ?} D -->|Oui| E[Émulateur / Simulateur] D -->|Non| F{Test de bout en bout ?} F -->|Oui| G{Candidat de version ?} G -->|Oui| H[Ferme de devices] G -->|Non| I[Émulateur / Simulateur] F -->|Non| J[Manuel ou exploratoire] C --> K[Retour rapide, faible fidélité] E --> K I --> K H --> L[Plus lent, haute fidélité] J --> M[Appareils réels de préférence]

Voici une règle empirique simple :

  • À chaque commit : exécutez les tests unitaires sur émulateur ou simulateur.
  • À chaque pull request : exécutez les tests unitaires ainsi que les tests d'intégration sur émulateur ou simulateur.
  • Avant un déploiement progressif ou une version par phases : exécutez la suite de tests complète sur une ferme de devices, couvrant un ensemble représentatif d'appareils.

La clé est d'adapter l'intensité des tests au risque. Une petite correction de bug dans une fonctionnalité interne ne nécessite pas une exécution complète sur une ferme de devices. Une version qui atteindra des milliers d'utilisateurs, absolument.

Une checklist pratique avant la soumission sur le store

Avant d'appuyer sur le bouton de soumission dans votre tableau de bord du store, parcourez cette checklist rapide :

  • Les tests unitaires réussissent sur émulateur ou simulateur pour les versions d'OS cibles.
  • Les tests d'intégration réussissent pour les flux utilisateur principaux (connexion, affichage des données, navigation).
  • Les tests UI réussissent sur au moins un émulateur et un appareil physique.
  • Les tests sur ferme de devices réussissent pour les 5 à 10 modèles d'appareils les plus utilisés par vos utilisateurs, selon vos analytics.
  • Aucun rapport de crash ou d'ANR (application ne répond pas) provenant de l'exécution sur la ferme de devices.
  • Les captures d'écran de la ferme de devices correspondent aux mises en page attendues sur différentes tailles d'écran.

Cette checklist n'est pas exhaustive, mais elle couvre les problèmes les plus courants qui passent en production.

L'essentiel à retenir

Tester uniquement sur des émulateurs, c'est comme essayer une voiture sur un parking. Cela vous dit que le volant fonctionne, mais pas comment la voiture se comporte sur l'autoroute. Les fermes de devices vous donnent des données d'autoroute. Utilisez les émulateurs pour la rapidité et les fermes de devices pour la confiance. Automatisez les deux dans votre pipeline, et vous livrerez moins de bugs et dormirez mieux la nuit.