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 shard per ridurre al minimo il tempo di completamento complessivo (quando termina l'ultimo shard). 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.
Suddividibile in parti 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) eventualmente eseguita una volta per ogni dispositivo coinvolto. Se la configurazione del modulo è lunga e costosa e non vale la pena di essere replicata rispetto al tempo di esecuzione del test, devi contrassegnare il modulo come non suddividibile in parti.
- Quando il numero di test nel modulo è ridotto:
Lo sharding di un modulo comporta l'eventuale 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, in genere non vale la pena installare un APK per un singolo test case.
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.
Pertanto, quando il numero di test nell'APK del test di misurazione è basso, il tagging del
modulo con <option name="not-shardable" value="true" /> consente al
harness di sapere che non vale la pena eseguire lo sharding del modulo.
Il runner AndroidJUnitTest ha un'opzione speciale che consente di specificare il
numero massimo di shard in cui è consentito suddividere:
<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.