Stratégies de test

Les tests automatisés vous aident à améliorer la qualité de votre application de plusieurs façons. Par exemple, il vous aide à effectuer la validation, à détecter les régressions et à vérifier la compatibilité. Une bonne stratégie de test vous permet de tirer parti des tests automatisés pour vous concentrer sur un avantage important : la productivité des développeurs.

Les équipes atteignent des niveaux de productivité plus élevés lorsqu'elles utilisent une approche systématique des tests associée à des améliorations de l'infrastructure. Cela permet d'obtenir rapidement des commentaires sur le comportement du code. Une bonne stratégie de test doit :

• Détecte les problèmes le plus tôt possible.
• S'exécute rapidement.
• Fournit des indications claires lorsqu'un problème doit être résolu.

Cette page vous aidera à choisir les types de tests à implémenter, où les exécuter et à quelle fréquence.

android skills add testing-setup

La pyramide de tests

Vous pouvez classer les tests par taille dans les applications modernes. Les petits tests se concentrent uniquement sur une petite partie du code, ce qui les rend rapides et fiables. Les tests de grande envergure ont une portée étendue et nécessitent des configurations plus complexes, difficiles à maintenir. Toutefois, les tests volumineux sont plus fidèles* et peuvent découvrir beaucoup plus de problèmes en une seule fois.

*Fidélité : fait référence à la similitude de l'environnement d'exécution des tests avec l'environnement de production.

La plupart des applications doivent comporter de nombreux petits tests et relativement peu de grands tests. La distribution des tests dans chaque catégorie doit former une pyramide, avec les nombreux petits tests formant la base et les grands tests moins nombreux formant la pointe.

Minimiser le coût d'un bug

Une bonne stratégie de test maximise la productivité des développeurs tout en minimisant le coût de la recherche de bugs.

Prenons l'exemple d'une stratégie potentiellement inefficace. Ici, le nombre de tests par taille ne s'organise pas en pyramide. Il y a trop de grands tests de bout en bout et trop peu de tests d'UI de composants :

Cela signifie que trop peu de tests sont exécutés avant la fusion. En cas de bug, il est possible que les tests ne le détectent pas avant l'exécution des tests de bout en bout quotidiens ou hebdomadaires.

Il est important de tenir compte des implications de ce phénomène sur le coût de l'identification et de la correction des bugs, et de comprendre pourquoi il est important d'orienter vos efforts de test vers des tests plus petits et plus fréquents :

• Lorsqu'un bug est détecté par un test unitaire, il est généralement corrigé en quelques minutes, ce qui représente un faible coût.
• Un test de bout en bout peut prendre des jours pour découvrir le même bug. Cela peut impliquer plusieurs membres de l'équipe, ce qui réduit la productivité globale et peut retarder une version. Le coût de ce bug est plus élevé.

Cela dit, une stratégie de test inefficace est toujours préférable à l'absence de stratégie. Lorsqu'un bug est détecté en production, la correction prend beaucoup de temps à arriver sur les appareils des utilisateurs (parfois des semaines). La boucle de rétroaction est donc la plus longue et la plus coûteuse.

Une stratégie de test évolutive

La pyramide de tests est traditionnellement divisée en trois catégories :

• Tests unitaires
• Tests d'intégration
• Tests de bout en bout.

Toutefois, ces concepts n'ont pas de définition précise. Les équipes peuvent donc définir leurs catégories différemment, par exemple en utilisant cinq niveaux :

• Un test unitaire est exécuté sur la machine hôte et vérifie une seule unité fonctionnelle de logique sans dépendance sur le framework Android.
  • Exemple : Vérification des erreurs de décalage d'une unité dans une fonction mathématique.
• Un test de composant vérifie la fonctionnalité ou l'apparence d'un module ou d'un composant indépendamment des autres composants du système. Contrairement aux tests unitaires, la surface de test d'un test de composant s'étend à des abstractions plus élevées que les méthodes et classes individuelles.
  • Exemple : test de capture d'écran pour un bouton personnalisé
• Un test de fonctionnalité vérifie l'interaction entre au moins deux composants ou modules indépendants. Les tests de fonctionnalités sont plus volumineux et plus complexes, et fonctionnent généralement au niveau des fonctionnalités.
  • Exemple : tests de comportement de l'UI qui vérifient la gestion de l'état sur un écran
• Un test d'application vérifie le fonctionnement de l'ensemble de l'application sous la forme d'un binaire déployable. Il s'agit de tests d'intégration volumineux qui utilisent un binaire débogable, tel qu'une version de développement pouvant contenir des hooks de test, comme système soumis aux tests.
  • Exemple : test du comportement de l'UI pour vérifier les modifications de configuration sur un appareil pliable, tests de localisation et d'accessibilité
• Un test de version candidate permet de vérifier la fonctionnalité d'une version. Ils sont semblables aux tests d'application, sauf que le binaire de l'application est minifié et optimisé. Il s'agit de grands tests d'intégration de bout en bout qui s'exécutent dans un environnement aussi proche que possible de la production sans exposer l'application à des comptes utilisateur publics ni à des backends publics.
  • Exemple : parcours utilisateur critiques, tests de performances

Cette catégorisation tient compte de la fidélité, du temps, de la portée et du niveau d'isolation. Vous pouvez effectuer différents types de tests sur plusieurs couches. Par exemple, le niveau de test de l'application peut contenir des tests de comportement, de capture d'écran et de performances.

Choisir la catégorie de test

En règle générale, vous devez tenir compte de la couche la plus basse de la pyramide qui peut fournir à l'équipe le bon niveau de commentaires.

Par exemple, réfléchissez à la manière de tester l'implémentation de cette fonctionnalité : l'UI d'un flux de connexion. En fonction de ce que vous devez tester, vous choisirez différentes catégories :

Dans certains cas, l'appartenance d'un élément à une catégorie ou à une autre peut être subjective. Il peut y avoir d'autres raisons pour lesquelles un test est déplacé vers le haut ou vers le bas, comme le coût de l'infrastructure, l'instabilité et la durée des tests.

Notez que la catégorie de test ne détermine pas le type de test et que toutes les fonctionnalités ne doivent pas être testées dans chaque catégorie.

Les tests manuels peuvent également faire partie de votre stratégie de test. En général, les équipes QA effectuent des tests sur les versions candidates, mais elles peuvent également être impliquées dans d'autres étapes. Par exemple, les tests exploratoires pour détecter les bugs dans une fonctionnalité sans script.

Infrastructure de test

Une stratégie de test doit être soutenue par une infrastructure et des outils qui aident les développeurs à exécuter leurs tests en continu et à appliquer des règles garantissant que tous les tests sont réussis.

Vous pouvez catégoriser les tests par portée pour définir quand et où exécuter chaque test. Par exemple, en suivant le modèle à cinq couches :

• Les tests Unit et Component s'exécutent sur le système d'intégration continue pour chaque nouveau commit, mais uniquement pour les modules concernés.
• Tous les tests Unit, Component et Feature sont exécutés avant la fusion ou l'envoi d'une modification.
• Les tests Application s'exécutent après la fusion.
• Les tests Release Candidate sont exécutés tous les soirs sur un téléphone, un appareil pliable et une tablette.
• Avant une version, les tests Release Candidate sont exécutés sur un grand nombre d'appareils.

Ces règles peuvent changer au fil du temps lorsque le nombre de tests affecte la productivité. Par exemple, si vous déplacez des tests vers une cadence nocturne, vous pouvez réduire les temps de compilation et de test CI, mais vous pouvez également prolonger la boucle de rétroaction.