Répondez à notre enquête sur la convivialité pour améliorer ce site.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Configurer le partage

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 le rationnel pour 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 pour réduire le temps d'achèvement global. Le harnais tente généralement d'équilibrer le temps d'exécution de chaque fragment pour 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 régler 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 faisceau qu'il ne doit pas être partitionné.

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 voudrez peut-être remplacer ce comportement:

  • Lorsque la configuration 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 à 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 de 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 pourriez vous retrouver avec un seul test ou pas de test dans certains fragments, ce qui rendrait toute étape de préparation assez coûteuse. L'installation d'un APK pour un seul scénario de test ne vaut généralement pas la peine, par exemple.

Tests d'instrumentation: nombre maximum de fragments?

Un test d'instrumentation exécuté via AndroidJUnitTest n'expose pas au harnais le nombre de tests faisant 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 de la suite.

Le harnais pourrait sur-fragmenter le test d'instrumentation et se retrouver avec des fragments vides; le partitionnement d'un test d'instrumentation avec cinq tests sur six fragments donne cinq fragments avec un test et un fragment 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, baliser le module avec <option name="not-shardable" value="true" /> permettrait au harnais de savoir que le partitionnement ne vaut pas la peine.

Le coureur AndroidJUnitTest a une option spéciale lui permettant de spécifier le nombre maximum de fragments dans <option name="ajur-max-shard" value="5" /> il est autorisé à partager: <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é au niveau d'appel. Par défaut, l'instrumentation sera fractionnée dans le 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 fragmenter, une valeur ajur-max-shard de 2 garantirait que vous ne créez pas de fragments vides.