Vous trouverez ci-dessous quelques formes d'automatisation classiques que vous pouvez utiliser dans votre système CI.
Jobs de base
Compiler:en compilant un projet à partir de zéro, vous vous assurez que les nouvelles modifications sont compilées correctement, et que tous les outils et bibliothèques sont compatibles les uns avec les autres.
Vérifications lint ou de style:il s'agit d'une étape facultative, mais recommandée. Lorsque vous appliquez des règles de style et effectuez une analyse statique, les revues de code peuvent être plus concises et plus ciblées.
Tests locaux ou côté hôte:ils s'exécutent sur l'ordinateur local qui effectue la compilation. Sur Android, il s'agit généralement de la JVM, qui est donc rapide et fiable. Ils comprennent également des tests Robolectric.
Tests instrumentés
Les tests exécutés sur des émulateurs ou des appareils physiques nécessitent un provisionnement, en attendant que les appareils démarrent ou soient connectés, et d'autres opérations qui ajoutent de la complexité.
Il existe plusieurs options pour exécuter des tests d'instrumentation dans la CI:
- Gradle Managed Devices (Appareils gérés par Gradle) permet de définir les appareils à utiliser (par exemple, "émulateur Pixel 2 sur l'API 27") et gère le provisionnement des appareils.
- La plupart des systèmes CI sont fournis avec un plug-in tiers (également appelé "action", "intégration" ou "étape") pour gérer les émulateurs Android.
- Déléguez les tests d'instrumentation à une batterie d'appareils telle que Firebase Test Lab. Les fermes d'appareils sont utilisées pour leur haute fiabilité et peuvent s'exécuter sur des émulateurs ou des appareils physiques.
Tests de régression des performances
Pour surveiller les performances de l'application, nous vous recommandons d'utiliser les bibliothèques d'analyse comparative. L'automatisation des tests de performances pendant le développement nécessite des appareils physiques pour garantir des résultats cohérents et réalistes.
L'exécution d'analyses comparatives peut prendre beaucoup de temps, en particulier lorsque vous avez une couverture élevée du code et des parcours utilisateur que vous comparez. Au lieu d'exécuter tous les benchmarks pour chaque fonctionnalité ou commit fusionné, envisagez de les exécuter dans le cadre d'une compilation de maintenance programmée de façon régulière, telle qu'une compilation nocturne.
Contrôle des performances
Vous pouvez surveiller les régressions de performances à l'aide de l'ajustement du pas. L'ajustement de pas définit une fenêtre glissante des résultats de la compilation précédente, que vous comparez à la compilation actuelle. Cette approche combine plusieurs résultats de benchmark dans une métrique spécifique à la régression. Vous pouvez appliquer l'ajustement de pas pour réduire le bruit lors des tests de régression.
Cela réduit l'occurrence de faux positifs qui peuvent se produire lorsque les temps de référence sont lents pour un seul build, puis sont à nouveau normalisés.
Tester les vérifications de régression de la couverture
La couverture des tests est une métrique qui peut vous aider, vous et votre équipe, à déterminer si les tests couvrent suffisamment une modification. Cependant, il ne devrait pas être le seul indicateur. Il est courant de configurer une vérification de régression qui échoue ou affiche un avertissement lorsque la couverture diminue par rapport à la branche de base.