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 logica del loro utilizzo.
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 sufficiente introspezione e abbiamo bisogno che il proprietario del modulo metta a punto alcuni comportamenti.
Frazionabile o non frazionabile?
È possibile contrassegnare un modulo ( AndroidTest.xml ) con <option name="not-shardable" value="true" /> per notificare al cablaggio che non deve essere suddiviso.
In un modulo tipico, lasciare che il cablaggio spezzi il 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 APK, push file, ecc.) eventualmente eseguita una volta per dispositivo coinvolto. Se la configurazione del modulo è lunga e costosa e non vale la pena replicarla rispetto al tempo di esecuzione del test, dovresti contrassegnare il modulo come non partizionabile.
- Quando il numero di test nel modulo è basso:
Lo sharding di un modulo fa sì che tutti i casi di test possano essere eseguiti in modo indipendente su dispositivi diversi. Ciò si riferisce al primo punto; se il numero di test è basso, potresti ritrovarti con un singolo test o nessun test in alcuni shard, il che renderebbe piuttosto costosa qualsiasi fase di preparazione. Ad esempio, di solito non vale la pena installare un APK per un singolo test case.
Test di strumentazione: numero massimo di frammenti?
Un test della strumentazione eseguito tramite AndroidJUnitTest non rivela al cablaggio quanti test fanno parte della strumentazione finché non installiamo ed eseguiamo effettivamente l'APK. Queste operazioni sono costose e non possono essere eseguite in fase di sharding per tutti i moduli facenti parte della suite.
L'imbracatura potrebbe frammentare eccessivamente il test della strumentazione e ritrovarsi con alcuni frammenti vuoti; frammentando un test di strumentazione con cinque test in sei frammenti si ottengono cinque frammenti con un test e uno senza test. Ciascuno di questi frammenti richiederebbe una costosa installazione APK.
Pertanto, quando il numero di test nell'APK del test di strumentazione è basso, contrassegnare 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 frammenti in cui è consentito eseguire il frammento: <option name="ajur-max-shard" value="5" /> .
Ciò consente di specificare un numero massimo di volte in cui è possibile eseguire il partizionamento della strumentazione indipendentemente dal numero di partizioni richieste a livello di chiamata. Per impostazione predefinita, la strumentazione verrà suddivisa nel numero di frammenti richiesti per l'invocazione.
Ad esempio, se l'APK del test di strumentazione contiene solo due casi di test ma desideri comunque frammentarlo, avere un valore ajur-max-shard pari a 2 ti garantirà di non creare shard vuoti.