Éléments à tester dans Android

Ce que vous devez tester dépend de facteurs tels que le type d'application, l'équipe de développement, la quantité d'ancien code et l'architecture utilisée. Les sections suivantes décrivent ce qu'un débutant peut prendre en compte lors de la planification des éléments à tester dans son application.

Organisation des répertoires de test

Un projet type dans Android Studio contient deux répertoires qui contiennent les tests en fonction de leur environnement d'exécution. Organisez vos tests dans les répertoires suivants, comme décrit ci-dessous:

  • Le répertoire androidTest doit contenir les tests exécutés sur des appareils réels ou virtuels. Ces tests incluent les tests d'intégration, les tests de bout en bout et d'autres tests dans lesquels la JVM seule ne peut pas valider le fonctionnement de votre application.
  • Le répertoire test doit contenir les tests qui s'exécutent sur votre ordinateur local, tels que les tests unitaires. Contrairement à ce qui précède, il peut s'agir de tests exécutés sur une JVM locale.

Tests unitaires essentiels

En suivant les bonnes pratiques, veillez à utiliser les tests unitaires dans les cas suivants:

  • Les tests unitaires pour les ViewModels ou les présentateurs.
  • Tests unitaires pour la couche de données, en particulier pour les dépôts. La majeure partie de la couche de données doit être indépendante de la plate-forme. Cela permet aux doubles de test de remplacer les modules de base de données et les sources de données distantes lors des tests. Consultez le guide sur l'utilisation des doubles de test sous Android.
  • Les tests unitaires pour d'autres couches indépendantes de la plate-forme, telles que la couche Domaine, comme avec les cas d'utilisation et les interactions.
  • Tests unitaires pour les classes utilitaires telles que la manipulation de chaînes et les calculs mathématiques.

Tester les cas limites

Les tests unitaires doivent se concentrer à la fois sur les cas normaux et extrêmes. Les cas limites sont des scénarios peu courants que les testeurs humains et les tests plus importants sont peu susceptibles de détecter. Voici quelques exemples:

  • Opérations mathématiques utilisant des nombres négatifs, des zéros et des conditions limites.
  • Toutes les erreurs de connexion réseau possibles.
  • Données corrompues (format JSON, par exemple)
  • Simuler le stockage complet lors de l'enregistrement dans un fichier
  • Objet recréé au milieu d'un processus (par exemple, une activité lors de la rotation de l'appareil).

Tests unitaires à éviter

Certains tests unitaires doivent être évités en raison de leur faible valeur:

  • Des tests qui vérifient le bon fonctionnement du framework ou d'une bibliothèque, et non de votre code.
  • Les points d'entrée du framework tels que les activités, les fragments ou les services ne doivent pas avoir de logique métier. Par conséquent, les tests unitaires ne doivent pas être une priorité. Les tests unitaires pour les activités n'ont que peu d'intérêt, car ils couvrent principalement le code du framework et nécessitent une configuration plus complexe. Les tests d'instrumentation tels que les tests d'interface utilisateur peuvent couvrir ces classes.

Tests de l'interface utilisateur

Vous devez effectuer plusieurs types de tests d'interface utilisateur:

  • Les tests de l'UI de l'écran vérifient les interactions utilisateur critiques sur un seul écran. Elles effectuent des actions telles que cliquer sur des boutons, saisir des formulaires et vérifier les états visibles. Une classe de test par écran est un bon point de départ.
  • Tests de parcours utilisateur ou tests de navigation, couvrant les chemins les plus courants. Ces tests simulent le déplacement d'un utilisateur dans un flux de navigation. Ce sont des tests simples, utiles pour vérifier les plantages au moment de l'exécution lors de l'initialisation.

Autres tests

Il existe des tests plus spécialisés, tels que des tests de capture d'écran, des tests de performance et des tests du singe. Vous pouvez également classer les tests par objectif, comme les régressions, l'accessibilité et la compatibilité.

Complément d'informations

Pour effectuer des tests isolés, vous devez souvent remplacer les dépendances du sujet testé par de fausses ou fictives, appelées "doubles de test" en général. Pour en savoir plus, consultez Utiliser les doubles de test sur Android.

Si vous souhaitez apprendre à créer des tests unitaires et des tests d'interface utilisateur, consultez les ateliers de programmation de test.