Questa pagina descrive cosa è possibile ottimizzare per un modulo della suite ( AndroidTest.xml ) tramite sharding e ottenere le migliori prestazioni di velocità durante l'esecuzione continua in laboratorio. Cercheremo di descrivere le opzioni in modo generico con la motivazione per l'utilizzo di ciascuna.
Quando si esegue continuamente una suite in laboratorio, la suite viene solitamente suddivisa su più dispositivi per ridurre il tempo di completamento complessivo. Il cablaggio in genere tenta di bilanciare il tempo di esecuzione di ogni frammento per ridurre al minimo il tempo di completamento complessivo (quando termina l'ultimo frammento); ma a causa della natura di alcuni test, non sempre abbiamo abbastanza introspezione e abbiamo bisogno che il proprietario del modulo metta a punto alcuni comportamenti.
Shardable o non shardable?
È possibile contrassegnare un modulo ( AndroidTest.xml ) con <option name="not-shardable" value="true" /> per notificare al cablaggio che non deve essere sottoposto a partizionamento.
In un modulo tipico, lasciare che l'imbracatura condivida il tuo modulo (il comportamento predefinito) è la cosa giusta da fare. Ma in alcuni casi, potresti voler ignorare quel comportamento:
- Quando la configurazione del tuo modulo è costosa:
Lo sharding di un modulo comporta la preparazione (installazione APK, file push, ecc.) possibilmente eseguita una volta per dispositivo coinvolto. Se la configurazione del tuo modulo è lunga e costosa e non vale la pena di essere replicata rispetto al runtime del test, dovresti contrassegnare il tuo modulo come non shardable.
- Quando il numero di test nel tuo modulo è basso:
Lo sharding di un modulo fa sì che tutti i casi di test possano essere eseguiti in modo indipendente su dispositivi diversi. Questo si riferisce al primo punto; se il tuo numero di test è basso, potresti ritrovarti con un singolo test o nessun test in alcuni frammenti, il che renderebbe piuttosto costoso qualsiasi passaggio di preparazione. Ad esempio, non vale la pena installare un APK per un singolo test case.
Test di strumentazione: numero massimo di frammenti?
Un test di strumentazione eseguito tramite AndroidJUnitTest non espone al cablaggio quanti test fanno parte della strumentazione fino a quando non installiamo ed eseguiamo effettivamente l'APK. Queste operazioni sono costose e non possono essere eseguite in fase di sharding per tutti i moduli che fanno parte della suite.
L'imbracatura potrebbe sovraccaricare il test della strumentazione e finire con alcuni frammenti vuoti; lo sharding di un test di strumentazione con cinque test in sei shard comporta cinque shard con un test e un shard senza test. Ciascuno di questi frammenti richiederebbe una costosa installazione di APK.
Quindi, quando il numero di test nell'APK del test di strumentazione è basso, taggare il modulo con <option name="not-shardable" value="true" /> consentirebbe al cablaggio di sapere che non vale la pena eseguire lo sharding di quel modulo.
Il runner AndroidJUnitTest ha un'opzione speciale che gli consente di specificare il numero massimo di shard in cui è consentito eseguire lo shard: <option name="ajur-max-shard" value="5" /> .
Ciò consente di specificare un numero massimo di volte in cui la strumentazione può essere partizionata indipendentemente dal numero di partizioni richieste a livello di chiamata. Per impostazione predefinita, la strumentazione verrà suddivisa nel numero di shard richiesti per l'invocazione.
Ad esempio, se il tuo APK di test di strumentazione contiene solo due casi di test ma desideri comunque eseguire lo shard, avere un valore ajur-max-shard pari a 2 ti assicurerà di non creare shard vuoti.