Configurer le partage

Cette page décrit ce qui est possible de régler pour un module de suite ( AndroidTest.xml ) via sharding et obtenir les meilleures performances de vitesse lors de l' exécution continue dans le laboratoire. Nous tenterons de décrire les options de manière générique avec le rationnel d'utilisation de chacune.

Lors de l'exécution continue d'une suite dans le laboratoire, la suite est généralement partagée sur plusieurs appareils afin de réduire le temps d'achèvement global. Le harnais tente généralement d'équilibrer le temps d'exécution de chaque partition pour minimiser le temps d'achèvement global (lorsque la dernière partition se termine) ; mais en raison de la nature de certains tests, nous n'avons pas toujours assez d'introspection et avons besoin du propriétaire du module pour régler certains comportements.

Partageable ou non partageable ?

Il est possible de marquer un module ( AndroidTest.xml ) avec <option name="not-shardable" value="true" /> l' <option name="not-shardable" value="true" /> pour informer le harnais qu'il ne doit pas être fragmentées.

Dans un module typique, laisser le fragment de harnais votre module (le comportement par défaut) est la bonne chose à faire. Mais dans certains cas, vous voudrez peut-être remplacer ce comportement :

  • Quand l'installation de votre module coûte cher :

Le partitionnement d'un module entraîne la préparation (installation d'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 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 a pour résultat que tous les cas de test peuvent 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. 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 maximum de fragments ?

Une course d'essai d'instrumentation par AndroidJUnitTest ne pas exposer au faisceau le nombre de tests font partie de l'instrumentation jusqu'à ce que nous installons et courons en fait 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, le marquage du module avec <option name="not-shardable" value="true" /> l' <option name="not-shardable" value="true" /> permettrait le faisceau de savoir sharding ce module est pas la peine.

Le AndroidJUnitTest coureur a une option spéciale permettant de spécifier le nombre maximum de tessons , il est autorisé à tesson dans: <option name="ajur-max-shard" value="5" /> l' <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 dans le nombre de fragments requis pour l'appel.

Par exemple, si votre test d'instrumentation APK ne contient que deux cas de test , mais vous voulez toujours Shard il, ayant une ajur-max-shard valeur de 2 serait vous assurer de ne pas créer des tessons vides.