Cette page décrit ce qu'il est possible de régler pour un module de suite (AndroidTest.xml) via le partitionnement et comment obtenir les meilleures performances de vitesse lors de l'exécution continue en laboratoire. Nous allons essayer de décrire les options de manière générique, en expliquant pourquoi utiliser chacune d'elles.
Lorsqu'une suite est exécutée en continu dans le laboratoire, elle est généralement fragmentée sur plusieurs appareils pour réduire le temps d'exécution global. Le harnais tente généralement d'équilibrer le temps d'exécution de chaque shard pour minimiser le temps d'exécution global (lorsque le dernier shard se termine). Toutefois, en raison de la nature de certains tests, nous ne disposons pas toujours de suffisamment d'introspection et nous avons besoin que le propriétaire du module ajuste certains comportements.
Partitionnable ou non partitionnable ?
Il est possible d'ajouter un tag (AndroidTest.xml) avec <option name="not-shardable" value="true" /> pour indiquer au harnais que le module ne doit pas être fragmenté.
Dans un module typique, il est judicieux de laisser le harnais fragmenter votre module (comportement par défaut). Toutefois, dans certains cas, vous pouvez remplacer ce comportement :
- Lorsque la configuration de votre module est coûteuse :
Le partitionnement d'un module entraîne la préparation (installation de l'APK, transfert du fichier, etc.) qui peut être exécutée une fois par appareil concerné. 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 à la durée d'exécution du test, vous devez marquer votre module comme non partitionnable.
- Lorsque le nombre de tests dans votre module est faible :
Le partitionnement d'un module permet d'exécuter tous les cas de test de manière indépendante sur différents appareils. Cela concerne le premier point : si votre nombre de tests est faible, vous risquez de vous retrouver avec un seul test ou aucun test dans certains shards, ce qui rendrait toute étape de préparation assez coûteuse. Par exemple, il ne vaut généralement pas la peine d'installer un APK pour un seul cas de test.
Tests d'instrumentation : nombre maximal de partitions ?
Un test d'instrumentation exécuté via AndroidJUnitTest n'indique pas au harnais le nombre de tests inclus dans l'instrumentation tant que nous n'avons pas installé et exécuté l'APK. Ces opérations sont coûteuses et ne peuvent pas être exécutées au moment du partitionnement pour tous les modules de la suite.
Le harnais peut sur-fragmenter le test d'instrumentation et se retrouver avec des fragments vides. Par exemple, le fractionnement d'un test d'instrumentation avec cinq tests en six fragments donne 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, le taggage du module avec <option name="not-shardable" value="true" /> permet au harnais de savoir que le partitionnement de ce module n'en vaut pas la peine.
Le coureur AndroidJUnitTest dispose d'une option spéciale lui permettant de spécifier le nombre maximal de partitions dans lesquelles il est autorisé à se partitionner : <option name="ajur-max-shard" value="5" />.
Cela vous permet de spécifier un nombre maximal de fois où l'instrumentation peut être fragmentée, quel que soit le nombre de fragments demandés au niveau de l'invocation. Par défaut, l'instrumentation est fragmentée en fonction du nombre de fragments demandés pour l'invocation.
Par exemple, si votre APK de test d'instrumentation ne contient que deux cas de test, mais que vous souhaitez quand même le partitionner, une valeur ajur-max-shard de 2 vous permettra de ne pas créer de partitions vides.