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 con il razionale per l'utilizzo di ciascuna.
Quando si esegue continuamente una suite nel lab, la suite viene in genere partizionata su più dispositivi per ridurre il tempo di completamento complessivo. L'imbracatura in genere tenta di bilanciare il tempo di esecuzione di ogni shard per ridurre al minimo il tempo di completamento complessivo (al termine dell'ultimo shard); ma a causa della natura di alcuni test, non abbiamo sempre abbastanza introspezione e abbiamo bisogno che il proprietario del modulo modifichi alcuni comportamenti.
Shardable o non shardabile?
È possibile contrassegnare un modulo ( AndroidTest.xml ) con <option name="not-shardable" value="true" /> per notificare all'imbracatura che non deve essere frammentato.
In un modulo tipico, lasciare che l'imbracatura suddivida il modulo (il comportamento predefinito) è la cosa giusta da fare. Ma in alcuni casi, potresti voler ignorare quel comportamento:
- Quando la configurazione del modulo è costosa:
Lo sharding di un modulo comporta la preparazione (installazione dell'APK, file push, ecc.) possibilmente eseguita una volta per dispositivo coinvolto. Se la configurazione del modulo è lunga e costosa e non vale la pena replicarla rispetto al runtime del test, è necessario contrassegnare il modulo come non partizionabile.
- 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 finire con un singolo test o nessun test in alcuni frammenti, il che renderebbe piuttosto costoso qualsiasi passaggio di preparazione. L'installazione di un APK per un singolo test case di solito non vale la pena, ad esempio.
Test della strumentazione: numero massimo di shard?
Un test della strumentazione eseguito tramite AndroidJUnitTest non espone 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 che fanno parte della suite.
L'imbracatura potrebbe sovraccaricare il test della strumentazione e finire con alcuni frammenti vuoti; il partizionamento orizzontale di un test della strumentazione con cinque test in sei frammenti produce cinque frammenti con un test e uno senza test. Ciascuno di questi frammenti richiederebbe una costosa installazione dell'APK.
Pertanto, quando il numero di test nell'APK di test della strumentazione è basso, contrassegnare il modulo con <option name="not-shardable" value="true" /> consentirebbe all'imbracatura di sapere che la partizionamento orizzontale di quel modulo non vale la pena.
Il corridore 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 partizioni di cui è possibile eseguire lo shard della strumentazione indipendentemente dal numero di shard richiesti a livello di chiamata. Per impostazione predefinita, la strumentazione verrà frammentata nel numero di shard richiesti per l'invocazione.
Ad esempio, se l'APK di test della strumentazione contiene solo due test case ma desideri comunque partizionarlo, avere un ajur-max-shard di 2 assicurerebbe di non creare frammenti vuoti.