Questa pagina descrive cosa è possibile ottimizzare per un modulo della suite
(AndroidTest.xml) tramite lo sharding e ottenere le migliori prestazioni di velocità durante
l'esecuzione continua nel lab. Cercheremo di descrivere le opzioni in modo generico, indicando la motivazione per cui utilizzare ciascuna.
Quando esegui continuamente una suite nel lab, questa viene solitamente suddivisa su più dispositivi per ridurre il tempo di completamento complessivo. Il framework in genere tenta di bilanciare il tempo di esecuzione di ogni shard per ridurre al minimo il tempo di completamento complessivo (quando termina l'ultimo shard), ma a causa della natura di alcuni test, non sempre abbiamo una conoscenza sufficiente e abbiamo bisogno che il proprietario del modulo ottimizzi alcuni comportamenti.
Suddivisibile o non suddivisibile?
È possibile taggare un modulo (AndroidTest.xml) con
<option name="not-shardable" value="true" /> per comunicare all'imbracatura che
non deve essere suddiviso.
In un modulo tipico, lasciare che l'harness esegua lo sharding del modulo (il comportamento predefinito) è la cosa giusta da fare. Ma in alcuni casi, potresti voler ignorare questo comportamento:
- Quando la configurazione del modulo è costosa:
Lo sharding di un modulo comporta la preparazione (installazione dell'APK, push del file e così via) che potrebbe essere eseguita una volta per ogni dispositivo coinvolto. Se la configurazione del modulo è lunga e costosa e non vale la pena di essere replicata rispetto alla durata di esecuzione del test, devi taggare il modulo come non partizionabile.
- Quando il numero di test nel modulo è basso:
Lo sharding di un modulo comporta l'esecuzione indipendente di tutti gli scenari di test su dispositivi diversi. Ciò si ricollega al primo punto: se il numero di test è basso, potresti ritrovarti con un solo test o nessun test in alcuni shard, il che renderebbe qualsiasi passaggio di preparazione piuttosto costoso. Ad esempio, l'installazione di un APK per un singolo scenario di test di solito non vale la pena.
Test di instrumentazione: numero massimo di shard?
Un test di instrumentazione eseguito tramite AndroidJUnitTest non espone all'ambiente di test il numero di test che fanno parte dell'instrumentazione finché non installiamo ed eseguiamo l'APK. Queste operazioni sono costose e non possono essere eseguite al momento dello sharding per tutti i moduli della suite.
L'imbracatura potrebbe suddividere eccessivamente il test di strumentazione e finire con alcuni shard vuoti; la suddivisione di un test di strumentazione con cinque test in sei shard genera cinque shard con un test e uno shard senza test. Ciascuno di questi shard richiederebbe un'installazione costosa dell'APK.
Pertanto, quando il numero di test nell'APK di test di instrumentazione è basso, il tagging del
modulo con <option name="not-shardable" value="true" /> consente
all'Harness di sapere che lo sharding di questo modulo non vale la pena.
Il runner AndroidJUnitTest ha un'opzione speciale che gli consente di specificare il numero massimo di shard in cui è consentito eseguire lo sharding:
<option name="ajur-max-shard" value="5" />.
In questo modo puoi specificare un numero massimo di volte in cui l'instrumentazione può essere suddivisa in shard, indipendentemente dal numero di shard richiesti a livello di invocazione. Per impostazione predefinita, la strumentazione verrà suddivisa nel numero di shard richiesti per l'invocazione.
Ad esempio, se l'APK di test di instrumentazione contiene solo due casi di test, ma
vuoi comunque suddividerlo, un valore ajur-max-shard pari a 2 ti assicura
di non creare shard vuoti.