Questa pagina descrive cosa è possibile ottimizzare per un modulo della suite
(AndroidTest.xml) tramite lo sharding e ottenere le migliori prestazioni in termini di velocità durante
l'esecuzione continua nel lab. Cercheremo di descrivere le opzioni in modo generico, fornendo la motivazione per l'utilizzo di ciascuna.
Quando esegui continuamente una suite nel lab, in genere viene suddivisa su più dispositivi per ridurre il tempo di completamento complessivo. In genere, il cablaggio tenta di bilanciare il tempo di esecuzione di ogni frammento per ridurre al minimo il tempo di completamento complessivo (quando termina l'ultimo frammento). Tuttavia, a causa della natura di alcuni test, non sempre abbiamo un'introspezione sufficiente e abbiamo bisogno che il proprietario del modulo ottimizzi alcuni comportamenti.
Può essere condiviso o meno?
È possibile taggare un modulo (AndroidTest.xml) con
<option name="not-shardable" value="true" /> per comunicare al cablaggio che
non deve essere suddiviso in parti.
In un modulo tipico, lasciare che il cablaggio shard il modulo (il comportamento predefinito) è la cosa giusta da fare. Tuttavia, 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 interessato. Se la configurazione del modulo è lunga e costosa e non vale la pena essere replicata rispetto al runtime del test, dovresti contrassegnare il modulo come non condivisibile.
- Quando il numero di test nel modulo è ridotto:
Lo sharding di un modulo comporta l'esecuzione indipendente di tutti gli scenari di test su dispositivi diversi. Questo è correlato al primo punto: se il numero di test è ridotto, potresti ritrovarti con un singolo test o nessun test in alcuni shard, il che renderebbe ogni passaggio di preparazione piuttosto costoso. Ad esempio, l'installazione di un APK per un singolo caso di test solitamente non vale la pena.
Test di strumentazione: numero massimo di shard?
Un test di strumentazione eseguito tramite AndroidJUnitTest non mostra all'harness quanti test fanno parte della strumentazione fino a quando non viene effettivamente installato e eseguito l'APK. Queste operazioni sono costose e non possono essere eseguite al momento dello sharding per tutti i moduli della suite.
Il cablaggio potrebbe suddividere eccessivamente il test di misurazione e generare alcuni shard vuoti. La suddivisione di un test di misurazione con cinque test in sei shard genera cinque shard con un test e uno senza test. Ognuno di questi frammenti richiederebbe un'installazione di APK dispendiosa.
Perciò, quando il numero di test nell'APK di test di strumentazione è basso, l'assegnazione di tag al modulo con <option name="not-shardable" value="true" /> permetterebbe all'applicazione di sapere che il partizionamento orizzontale non vale la pena eseguire il partizionamento orizzontale del modulo.
Il runner AndroidJUnitTest ha un'opzione speciale che consente di specificare il
numero massimo di shard in cui può eseguire lo sharding:
<option name="ajur-max-shard" value="5" />.
In questo modo puoi specificare il numero massimo di volte in cui la misurazione può essere suddivisa in parti, indipendentemente dal numero di parti richieste a livello di chiamata. Per impostazione predefinita, la misurazione verrà suddivisa in base al numero di shard richiesti per l'invocazione.
Ad esempio, se l'APK del test di misurazione contiene solo due casi di test, ma vuoi comunque eseguirne lo sharding, un valore ajur-max-shard pari a 2 ti garantirà di non creare shard vuoti.