Cette page décrit ce qu'il est possible de régler pour un module de suite ( AndroidTest.xml
) via le partitionnement et d'obtenir les meilleures performances de vitesse lors d'une exécution continue dans le laboratoire. Nous tenterons de décrire les options de manière générique avec la justification de leur utilisation.
Lors de l'exécution continue d'une suite dans le laboratoire, celle-ci est généralement partagée 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'achèvement 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 ajuster certains comportements.
Shardable ou non partageable ?
Il est possible de baliser un module ( AndroidTest.xml
) avec <option name="not-shardable" value="true" />
pour avertir le harnais qu'il ne doit pas être fragmenté.
Dans un module typique, laisser le harnais fragmenter votre module (le comportement par défaut) est la bonne chose à faire. Mais dans certains cas, vous souhaiterez peut-être remplacer ce comportement :
- Lorsque la mise en place de votre module coûte cher :
Le partage d'un module entraîne la préparation (installation de l'APK, fichier push, etc.) éventuellement exécutée une fois par appareil impliqué. Si la configuration de votre module est longue et coûteuse et ne vaut pas la peine d'être répliquée par rapport au temps d'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 permet à tous les cas de test de s'exécuter indépendamment 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. Par exemple, installer un APK pour un seul scénario de test n’en vaut généralement pas la peine.
Tests d'instrumentation : Nombre maximum de fragments ?
Un test d'instrumentation exécuté via AndroidJUnitTest n'expose pas au harnais 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 pas être exécutées au moment du sharding pour tous les modules faisant partie de la suite.
Le harnais pourrait 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 tests. Chacun de ces fragments nécessiterait une installation coûteuse d’APK.
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 partitionnement de ce module n'en vaut pas la peine.
Le programme d'exécution AndroidJUnitTest
dispose d'une option spéciale lui permettant de spécifier le nombre maximum de fragments dans lesquels il est autorisé à fragmenter : <option name="ajur-max-shard" value="5" />
.
Cela vous permet de spécifier un nombre maximum 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 selon le nombre de fragments demandé 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, avoir une valeur ajur-max-shard
de 2
garantira que vous ne créez pas de partitions vides.