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
e di fornire la motivazione per l'utilizzo di ciascuna.
Quando viene eseguita continuamente una suite nel lab, questa viene solitamente suddivisa su più dispositivi per ridurre il tempo di completamento complessivo. Il framework in genere tenta di bilanciare il tempo di esecuzione di ogni shard per ridurre al minimo il tempo di completamento complessivo (quando termina l'ultimo shard), ma a causa della natura di alcuni test, non sempre abbiamo una conoscenza sufficiente e abbiamo bisogno che il proprietario del modulo ottimizzi alcuni comportamenti.
Suddivisibile o non suddivisibile?
È possibile taggare un modulo (AndroidTest.xml) con
<option name="not-shardable" value="true" /> per comunicare all'imbracatura che
non deve essere suddiviso.
In un modulo tipico, lasciare che l'harness esegua lo sharding del 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 dell'APK, push del file e così via) che potrebbe essere eseguita una volta per ogni dispositivo coinvolto. Se la configurazione del modulo è lunga e costosa e non vale la pena di essere replicata rispetto alla durata del test, devi taggare il modulo come non partizionabile.
- Quando il numero di test nel modulo è basso:
Lo sharding di un modulo comporta l'esecuzione indipendente di tutti gli scenari di test su dispositivi diversi. Ciò si ricollega al primo punto: se il numero di test è basso, potresti ritrovarti con un solo test o nessun test in alcuni shard, il che renderebbe piuttosto costoso qualsiasi passaggio di preparazione. L'installazione di un APK per un singolo scenario di test di solito non vale la pena, ad esempio.
Test di instrumentazione: numero massimo di shard?
Un test di instrumentazione eseguito tramite AndroidJUnitTest non espone all'ambiente di test il numero di test che fanno parte dell'instrumentazione finché non installiamo ed eseguiamo l'APK. Queste operazioni sono costose e non possono essere eseguite al momento dello sharding per tutti i moduli della suite.
L'imbracatura potrebbe suddividere eccessivamente il test di strumentazione e finire con alcuni shard vuoti; la suddivisione di un test di strumentazione con cinque test in sei shard genera cinque shard con un test e uno shard senza test. Ciascuno di questi shard richiederebbe un'installazione APK costosa.
Pertanto, quando il numero di test nell'APK di test di instrumentazione è basso, il tagging del
modulo con <option name="not-shardable" value="true" /> consente
all'ambiente di test di sapere che lo sharding di questo modulo non vale la pena.
Il runner AndroidJUnitTest ha un'opzione speciale che gli consente di specificare il numero massimo di shard in cui è consentito eseguire lo sharding:
<option name="ajur-max-shard" value="5" />.
In questo modo puoi specificare un numero massimo di volte in cui lo sharding può essere eseguito indipendentemente dal numero di shard richiesti a livello di invocazione. Per impostazione predefinita, la strumentazione verrà suddivisa nel numero di shard richiesti per l'invocazione.
Ad esempio, se l'APK di test di instrumentazione contiene solo due casi di test, ma
vuoi comunque suddividerlo, un valore ajur-max-shard pari a 2 ti assicura
di non creare shard vuoti.