Cette page décrit ce que vous pouvez ajuster pour un module de suite (AndroidTest.xml) via le fractionnement et obtenir les meilleures performances de vitesse lors de l'exécution continue en laboratoire. Nous allons tenter de décrire les options de manière générique, en indiquant la raison d'utiliser chacune d'elles.
Lorsque vous exécutez en continu une suite dans l'atelier, elle est généralement fractionnée sur plusieurs appareils afin de réduire le temps de traitement global. Le harnais tente généralement d'équilibrer le temps d'exécution de chaque segment afin de réduire la durée d'exécution globale (lorsque le dernier segment se termine). Toutefois, en raison de la nature de certains tests, nous n'avons pas toujours suffisamment d'introspection et nous avons besoin du propriétaire du module pour ajuster certains comportements.
Partitionnable ou non segmentable ?
Il est possible d'ajouter un tag <option name="not-shardable" value="true" /> à un module (AndroidTest.xml) pour avertir l'équipe qu'il ne doit pas être segmenté.
Dans un module type, il est recommandé de laisser l'outil exploiter segmenter votre module (comportement par défaut). Toutefois, dans certains cas, vous pouvez ignorer ce comportement:
- Lorsque la configuration de votre module est coûteuse:
Le fractionnement d'un module entraîne l'exécution de la préparation (installation de l'APK, transfert de fichier, etc.) une fois par appareil impliqué. Si la configuration de votre module est longue et coûteuse, et qu'elle ne vaut pas la peine d'être répliquée par rapport à l'environnement d'exécution du test, vous devez marquer votre module comme non segmentable.
- Lorsque le nombre de tests de votre module est faible:
Le fractionnement d'un module permet d'exécuter tous les cas de test indépendamment sur différents appareils. Cela concerne le premier point. Si le nombre de tests est faible, vous risquez de n'en avoir qu'un seul ou aucun dans certains fragments, ce qui rendrait toute étape de préparation très coûteuse. L'installation d'un APK pour un seul scénario de test n'en vaut généralement pas la peine, par exemple.
Tests d'instrumentation: nombre maximal de segments ?
Un test d'instrumentation exécuté via AndroidJUnitTest n'expose pas au harnais le nombre de tests qui font partie de l'instrumentation tant que nous n'avons pas réellement installé et exécuté l'APK. Ces opérations sont coûteuses et ne peuvent pas être exécutées au moment du fractionnement pour tous les modules de la suite.
Le harnais peut trop diviser le test d'instrumentation et se retrouver avec des fragments vides. Si vous divisez un test d'instrumentation en cinq tests sur six fragments, vous obtiendrez cinq fragments avec un test et un fragment sans test. Chacun de ces fragments nécessiterait une installation d'APK coûteuse.
Ainsi, lorsque le nombre de tests dans l'APK de test d'instrumentation est faible, ajouter le tag <option name="not-shardable" value="true" /> au module permet de savoir si la segmentation de ce module n'en vaut pas la peine.
Le programmeur AndroidJUnitTest dispose d'une option spéciale lui permettant de spécifier le nombre maximal de partitions dans lesquelles il est autorisé à diviser : <option name="ajur-max-shard" value="5" />.
Vous pouvez ainsi spécifier le nombre maximal de fois où l'instrumentation peut être fractionnée, quel que soit le nombre de fragments demandés au niveau de l'appel. Par défaut, l'instrumentation sera divisée en fonction du nombre de fragments demandés pour l'appel.
Par exemple, si votre APK de test d'instrumentation ne contient que deux scénarios de test, mais que vous souhaitez tout de même le partitionner, une valeur ajur-max-shard de 2 vous permet de vous assurer que vous ne créez pas de partitions vides.