Tester différentes tailles d'écran et de fenêtre

Les tests font partie intégrante du processus de développement des applications. Vous exécutez généralement des applications sur un émulateur ou un appareil pour vérifier manuellement que votre code fonctionne comme prévu. Toutefois, les tests manuels sont chronophages, sujets à des erreurs et souvent ingérables pour les applications exécutées sur des écrans et des appareils de différentes tailles. Les problèmes liés aux tests manuels découlent le plus souvent de l'utilisation d'un seul appareil pour le développement. Par conséquent, les erreurs peuvent passer inaperçues sur d'autres appareils ayant des facteurs de forme différents.

Pour identifier les régressions sur différentes tailles de fenêtre et d'écran, implémentez des tests automatisés afin de vérifier que le comportement et l'apparence de votre application sont cohérents sur différents facteurs de forme. Les tests automatisés identifient les problèmes à un stade précoce, ce qui réduit le risque qu'ils n'affectent l'expérience utilisateur.

Que faut-il tester ?

Lorsque vous développez des interfaces utilisateur conçues pour différentes tailles d'écran et de fenêtre, portez une attention particulière à deux aspects:

1. Différences entre les attributs visuels des composants et des mises en page sur des fenêtres de différentes tailles
2. Préserver l'état lors des modifications de la configuration

Attributs visuels

Que vous personnalisiez les interfaces utilisateur pour différentes tailles de fenêtre ou non, vous devez vérifier qu'elles s'affichent correctement. Tenez compte des largeurs et des hauteurs compactes, moyennes et étendues. Consultez la section Classes de taille de fenêtre pour connaître les points d'arrêt recommandés.

En outre, il est possible que votre application n'affiche pas certains composants de votre système de conception comme prévu lorsque leurs contraintes de taille sont étirées.

Si votre application dispose de mises en page adaptatives pour différentes tailles de fenêtre, vous devez effectuer des tests automatisés pour éviter les régressions. Par exemple, la correction d'une marge sur un téléphone peut entraîner des incohérences de mise en page sur une tablette. Créez des tests d'interface utilisateur pour vérifier le comportement de vos mises en page et de vos composants, ou créez des tests de capture d'écran pour vérifier visuellement les mises en page.

Restauration de l'état

Les applications exécutées sur des appareils tels que les tablettes sont pivotées et redimensionnées beaucoup plus fréquemment que les applications sur les téléphones. En outre, les appareils pliables introduisent de nouvelles fonctionnalités d'affichage, telles que le pliage et le dépliage, qui peuvent déclencher des modifications de la configuration. Votre application doit pouvoir restaurer l'état lorsque ces modifications de configuration se produisent. Vous devez également écrire des tests qui confirment que votre application restaure correctement l'état.

Tout d'abord, vérifiez que votre application ne plante pas en cas de modification de la configuration. Assurez-vous que chaque interface utilisateur de votre application peut gérer n'importe quelle combinaison de rotation, de redimensionnement ou de pliage. Étant donné que les modifications de configuration recréent l'activité par défaut, certains plantages se produisent en raison de l'hypothèse de persistance de l'activité.

Il existe plusieurs façons de tester les modifications de configuration, mais dans la plupart des cas, il existe deux façons de les tester:

• Dans Compose, utilisez StateRestorationTester pour simuler un changement de configuration de manière efficace sans redémarrer l'activité. Pour en savoir plus, consultez les sections suivantes.
• Dans n'importe quel test d'interface utilisateur tel qu'Espresso ou Compose, simulez un changement de configuration en appelant Activity.recreate().

En règle générale, vous n'avez pas besoin d'utiliser différents appareils pour tester la restauration de l'état en réponse aux modifications de configuration. En effet, toutes les modifications de configuration qui recréent l'activité ont des répercussions similaires. Cependant, certaines modifications de configuration peuvent déclencher différents mécanismes de restauration de l'état sur des appareils spécifiques.

Par exemple, lorsqu'un utilisateur consulte une interface utilisateur liste/détails sur un appareil pliable ouvert et qu'il plie l'appareil pour passer à l'écran frontal, l'UI bascule généralement sur la page d'informations. Un test automatisé doit couvrir cette restauration de l'état de l'interface utilisateur, y compris l'état de navigation.

Pour tester les modifications de configuration qui se produisent sur les appareils qui passent d'un écran à un autre ou qui passent en mode multifenêtre, plusieurs options s'offrent à vous:

• Sur n'importe quel appareil, redimensionnez l'écran pendant un test. Dans la plupart des cas, cela déclenche tous les mécanismes de restauration d'état que vous devez vérifier. Toutefois, ce test ne fonctionnera pas pour la logique qui détecte des positions spécifiques dans les pliables, car les changements de position ne déclenchent pas de changement de configuration.
• Déclenchez les modifications de configuration associées à l'aide d'un appareil ou d'un émulateur compatible avec les fonctionnalités que vous souhaitez tester. Par exemple, un appareil pliable ou une tablette peut être contrôlé à l'aide d'Espresso Device pour passer d'un appareil plié à un écran plat dans un environnement paysage. Consultez la section Espresso Device (Appareil Espresso) de Bibliothèques et outils pour tester différentes tailles d'écran pour obtenir des exemples.

Types de tests pour différentes tailles d'écran et de fenêtre

Utilisez le type de test approprié pour chaque cas d'utilisation afin de vérifier que le test fonctionne correctement sur différents facteurs de forme:

• Les tests de comportement de l'interface utilisateur lancent une partie de l'interface utilisateur de l'application, comme l'affichage d'une activité. Les tests vérifient que certains éléments existent ou possèdent des attributs spécifiques . Les tests peuvent éventuellement exécuter des actions utilisateur simulées. Pour les vues, utilisez Espresso. Jetpack Compose dispose de ses propres API de test. Les tests de comportement de l'interface utilisateur peuvent être instrumentés ou en local. Les tests d'instrumentation s'exécutent sur des appareils ou des émulateurs, tandis que les tests d'interface utilisateur locaux s'exécutent sur Robolectric sur la JVM.

  Utilisez des tests de comportement de l'interface utilisateur pour vérifier que l'implémentation de la navigation dans une application est correcte. Les tests effectuent des actions telles que les clics et les balayages. Les tests de comportement de l'interface utilisateur vérifient également l'existence de certains éléments ou propriétés. Pour en savoir plus, consultez la section Automatiser les tests de l'interface utilisateur.

• Les tests de capture d'écran effectuent une capture d'écran d'une interface utilisateur ou d'un composant, et comparent l'image à une capture d'écran précédemment approuvée. C'est un moyen très efficace de se protéger contre les régressions, car une seule capture d'écran peut couvrir un grand nombre d'éléments et leurs propriétés visuelles. Vous pouvez exécuter des tests de captures d'écran sur la JVM ou sur des appareils. Plusieurs frameworks de test de captures d'écran sont disponibles.

Enfin, vous aurez peut-être besoin de tests unitaires pour tester le fonctionnement d'unités de logique qui se comportent différemment selon le type d'appareil ou la taille de la fenêtre, mais les tests unitaires sont moins courants dans cette zone.

Étapes suivantes

Pour en savoir plus sur la mise en œuvre des vérifications contenues dans ce document, consultez Bibliothèques et outils.