Na tej stronie opisano, co można dostroić dla modułu pakietu ( AndroidTest.xml ) za pomocą fragmentowania i uzyskać najlepszą wydajność podczas ciągłego wykonywania w laboratorium. Spróbujemy opisać opcje w sposób ogólny, podając uzasadnienie użycia każdej z nich.
W przypadku ciągłego uruchamiania pakietu w laboratorium, pakiet jest zwykle dzielony na kilka urządzeń, aby skrócić ogólny czas ukończenia. Uprząż zazwyczaj próbuje zrównoważyć czas wykonania każdego fragmentu, aby zminimalizować całkowity czas ukończenia (kiedy zakończy się ostatni fragment); ale ze względu na naturę niektórych testów nie zawsze mamy wystarczającą introspekcję i potrzebujemy, aby właściciel modułu dostroił pewne zachowanie.
Shardable czy nie shardable?
Możliwe jest oznaczenie modułu ( AndroidTest.xml ) za pomocą <option name="not-shardable" value="true" /> aby powiadomić wiązkę przewodów, że nie powinna być dzielona na fragmenty.
W typowym module, właściwym rozwiązaniem jest pozwolenie fragmentowi wiązki przewodów na fragment modułu (zachowanie domyślne). Ale w niektórych przypadkach możesz chcieć zastąpić to zachowanie:
- Gdy konfiguracja modułu jest kosztowna:
Dzielenie modułu na fragmenty powoduje, że przygotowanie (instalacja pliku APK, wypychanie pliku itp.) może zostać uruchomione raz na każde urządzenie. Jeśli konfiguracja modułu jest długa i kosztowna i nie warto jej replikować w porównaniu ze środowiskiem wykonawczym testu, powinieneś oznaczyć moduł jako niemożliwy do fragmentowania.
- Gdy liczba testów w Twoim module jest niska:
Dzielenie modułu na fragmenty powoduje, że wszystkie przypadki testowe mogą być wykonywane niezależnie na różnych urządzeniach. Odnosi się to do pierwszego punktu; jeśli liczba testów jest niska, może się okazać, że w niektórych fragmentach zostanie wykonany pojedynczy test lub nie będzie żadnego testu, co sprawi, że każdy etap przygotowawczy będzie dość kosztowny. Na przykład instalowanie pakietu APK dla pojedynczego przypadku testowego zwykle nie jest tego warte.
Testy oprzyrządowania: maksymalna liczba odłamków?
Test oprzyrządowania przeprowadzany za pomocą narzędzia AndroidJUnitTest nie ujawnia oprogramowaniu, ile testów stanowi część oprzyrządowania, dopóki nie zainstalujemy i nie uruchomimy pakietu APK. Operacje te są kosztowne i nie można ich wykonać podczas fragmentowania wszystkich modułów wchodzących w skład pakietu.
Uprząż może spowodować nadmierne odłamki testu oprzyrządowania i skończyć z kilkoma pustymi odłamkami; sharding testu oprzyrządowania z pięcioma testami w sześciu fragmentach skutkuje pięcioma fragmentami z jednym testem i jednym fragmentem bez testów. Każdy z tych fragmentów wymagałby kosztownej instalacji pakietu APK.
Tak więc, gdy liczba testów w pliku APK testu oprzyrządowania jest niska, oznaczenie modułu za pomocą <option name="not-shardable" value="true" /> pozwoli wiązce wiedzieć, że fragmentowanie tego modułu nie jest tego warte.
Moduł uruchamiający AndroidJUnitTest ma specjalną opcję pozwalającą określić maksymalną liczbę fragmentów, na które można podzielić: <option name="ajur-max-shard" value="5" /> .
Umożliwia to określenie maksymalnej liczby fragmentów instrumentacji, niezależnie od liczby fragmentów żądanych na poziomie wywołania. Domyślnie oprzyrządowanie zostanie podzielone na liczbę fragmentów wymaganą do wywołania.
Na przykład, jeśli plik APK do testowania oprzyrządowania zawiera tylko dwa przypadki testowe, ale nadal chcesz go podzielić na fragmenty, posiadanie wartości ajur-max-shard równej 2 zapewni, że nie utworzysz pustych fragmentów.