Cette page décrit ce qu'il est possible de régler pour un module de suite ( AndroidTest.xml ) via le sharding et d'obtenir les meilleures performances de vitesse lors d'une exécution continue en laboratoire. Nous tenterons de décrire les options de manière générique avec la justification de l'utilisation de chacune.
Lors de l'exécution continue d'une suite dans le laboratoire, la suite est généralement répartie sur plusieurs appareils afin de réduire le temps d'exécution global. Le harnais tente généralement d'équilibrer le temps d'exécution de chaque fragment afin de minimiser le temps d'exécution global (lorsque le dernier fragment se termine) ; mais en raison de la nature de certains tests, nous n'avons pas toujours suffisamment d'introspection et avons besoin du propriétaire du module pour régler certains comportements.
Partageable ou non partageable ?
Il est possible de taguer un module ( AndroidTest.xml ) avec <option name="not-shardable" value="true" /> pour notifier au harnais qu'il ne doit pas être shardé.
Dans un module typique, laisser le faisceau fragmenter votre module (le comportement par défaut) est la bonne chose à faire. Mais dans certains cas, vous souhaiterez peut-être remplacer ce comportement :
- Quand la mise en place de votre module coûte cher :
Le sharding d'un module entraîne la préparation (installation APK, fichier push, etc.) éventuellement exécutée une fois par appareil concerné. Si la configuration de votre module est longue et coûteuse et ne vaut pas la peine d'être répliquée par rapport à l'exécution du test, vous devez marquer votre module comme non partageable.
- Lorsque le nombre de tests dans votre module est faible :
Le partage d'un module entraîne l'exécution indépendante de tous les cas de test sur différents appareils. Cela concerne le premier point; si votre nombre de tests est faible, vous pourriez vous retrouver avec un seul test ou aucun test dans certaines partitions, ce qui rendrait toute étape de préparation assez coûteuse. L'installation d'un APK pour un seul cas de test n'en vaut généralement pas la peine, par exemple.
Tests d'instrumentation : nombre max de shards ?
Un test d'instrumentation exécuté via AndroidJUnitTest n'indique pas au faisceau combien de tests font partie de l'instrumentation jusqu'à ce que nous installions et exécutions réellement l'APK. Ces opérations sont coûteuses et ne peuvent être exécutées au moment du sharding pour tous les modules faisant partie de la suite.
Le harnais peut surcharger le test d'instrumentation et se retrouver avec des fragments vides ; le partitionnement d'un test d'instrumentation avec cinq tests dans six partitions donne cinq partitions avec un test et une partition sans test. Chacun de ces fragments nécessiterait une installation APK coûteuse.
Ainsi, lorsque le nombre de tests dans l'APK de test d'instrumentation est faible, marquer le module avec <option name="not-shardable" value="true" /> permettrait au harnais de savoir que le partage de ce module n'en vaut pas la peine.
L'exécuteur AndroidJUnitTest a une option spéciale lui permettant de spécifier le nombre maximum de partitions dans lesquelles il est autorisé à partitionner : <option name="ajur-max-shard" value="5" /> .
Cela vous permet de spécifier un nombre maximal de fois où l'instrumentation peut être partitionnée, quel que soit le nombre de partitions demandées au niveau de l'appel. Par défaut, l'instrumentation sera fragmentée en nombre de fragments demandés pour l'appel.
Par exemple, si votre APK de test d'instrumentation ne contient que deux cas de test mais que vous souhaitez toujours le partitionner, le fait d'avoir une valeur ajur-max-shard de 2 garantirait que vous ne créez pas de partitions vides.