Configura sharding

Questa pagina descrive ciò che è possibile sintonizzarsi per un modulo 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 il razionale per l'utilizzo di ciascuna.

Quando si esegue continuamente una suite in laboratorio, la suite viene solitamente suddivisa in 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 l'ultimo frammento termina); 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.

Divisibile o non partizionabile?

E 'possibile contrassegnare un modulo ( AndroidTest.xml ) con <option name="not-shardable" value="true" /> per notificare l'imbracatura che non dovrebbe essere sharded.

In un modulo tipico, lasciare che il cablaggio shard il modulo (il comportamento predefinito) è la cosa giusta da fare. Ma in alcuni casi, potresti voler sovrascrivere quel comportamento:

  • Quando l'installazione del 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 modulo è lunga e costosa e non vale la pena di essere replicata rispetto al runtime del test, è necessario contrassegnare il modulo come non condivisibile.

  • Quando il numero di test nel modulo è basso:

Lo sharding di un modulo comporta l'esecuzione indipendente di tutti i casi di test su dispositivi diversi. Ciò 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 qualsiasi fase di preparazione piuttosto costosa. 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 di strumentazione in esecuzione attraverso AndroidJUnitTest non espone al fascio di quanti test fanno parte della strumentazione fino a quando abbiamo effettivamente installare ed eseguire l'APK. Queste operazioni sono costose e non possono essere eseguite al momento dello sharding per tutti i moduli della suite.

L'imbracatura potrebbe sovraccaricare il test della strumentazione e finire con alcuni frammenti vuoti; il frammento di un test di strumentazione con cinque test in sei frammenti risulta in cinque frammenti con un test e un frammento senza test. Ciascuno di questi frammenti richiederebbe una costosa installazione dell'APK.

Così, quando il numero di test nel test di APK strumentazione è bassa, tagging il modulo con <option name="not-shardable" value="true" /> permetterebbe l'imbracatura di sapere sharding quel modulo non vale la pena.

AndroidJUnitTest corridore ha un'opzione speciale gli permette di specificare il numero massimo di frammenti ad essa riservate shard in: <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 frammenti richiesti per l'invocazione.

Ad esempio, se l'APK di test strumentazione contiene solo due casi di test, ma si vuole ancora coccio, avendo un ajur-max-shard valore del 2 garantirebbe non si sta creando frammenti vuoti.