Cette page décrit ce que vous pouvez ajuster pour un module de suite (AndroidTest.xml) via le fractionnement et obtenir les meilleures performances de vitesse lors de l'exécution continue en laboratoire. Nous allons tenter de décrire les options de manière générique, en indiquant la raison d'utiliser chacune d'elles.
Lorsque vous exécutez en continu une suite dans l'atelier, elle est généralement fractionnée sur plusieurs appareils afin de réduire le temps de traitement global. Le harnais tente généralement d'équilibrer le temps d'exécution de chaque segment afin de réduire la durée d'exécution globale (lorsque le dernier segment se termine). Toutefois, en raison de la nature de certains tests, nous n'avons pas toujours suffisamment d'introspection et nous avons besoin du propriétaire du module pour ajuster certains comportements.
Peut-il être partitionné ?
Vous pouvez taguer un module (AndroidTest.xml) avec <option name="not-shardable" value="true" /> pour indiquer au harnais qu'il ne doit pas être fractionné.
Dans un module typique, laisser le harnais diviser votre module (comportement par défaut) est la bonne chose à faire. Toutefois, dans certains cas, vous pouvez ignorer ce comportement:
- Lorsque la configuration de votre module est coûteuse:
Le fractionnement d'un module entraîne l'exécution de la préparation (installation de l'APK, transfert de fichier, etc.) une fois par appareil impliqué. 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 au temps d'exécution du test, vous devez taguer votre module comme non partitionnable.
- Lorsque le nombre de tests de votre module est faible:
Le fractionnement d'un module permet d'exécuter tous les cas de test indépendamment sur différents appareils. Cela concerne le premier point. Si le nombre de tests est faible, vous risquez de n'en avoir qu'un seul ou aucun dans certains fragments, ce qui rendrait toute étape de préparation très coûteuse. Par exemple, installer un APK pour un seul cas de test n'est généralement pas rentable.
Tests d'instrumentation: nombre maximal de partitions ?
Un test d'instrumentation exécuté via AndroidJUnitTest n'expose pas au harnais le nombre de tests qui font partie de l'instrumentation tant que nous n'avons pas réellement installé et exécuté l'APK. Ces opérations sont coûteuses et ne peuvent pas être exécutées au moment du fractionnement pour tous les modules de la suite.
Le harnais peut trop diviser le test d'instrumentation et se retrouver avec des fragments vides. Si vous divisez un test d'instrumentation en cinq tests sur six fragments, vous obtiendrez cinq fragments avec un test et un fragment sans test. Chacun de ces fragments nécessiterait une installation d'APK coûteuse.
Par conséquent, 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 fractionnement de ce module n'est pas intéressant.
Le programmeur AndroidJUnitTest dispose d'une option spéciale lui permettant de spécifier le nombre maximal de partitions dans lesquelles il est autorisé à diviser : <option name="ajur-max-shard" value="5" />.
Vous pouvez ainsi spécifier le nombre maximal de fois où l'instrumentation peut être fractionnée, quel que soit le nombre de fragments demandés au niveau de l'appel. Par défaut, l'instrumentation sera divisée en fonction du nombre de segments demandés pour l'appel.
Par exemple, si votre APK de test d'instrumentation ne contient que deux scénarios de test, mais que vous souhaitez tout de même le partitionner, une valeur ajur-max-shard de 2 vous permet de vous assurer que vous ne créez pas de partitions vides.