Na tej stronie opisano, co można dostroić pod kątem 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 z uzasadnieniem 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ć całkowity czas ukończenia. Uprząż zazwyczaj próbuje zrównoważyć czas wykonania każdego fragmentu, aby zminimalizować całkowity czas ukończenia (kiedy ostatni fragment się skończy); ale ze względu na charakter niektórych testów nie zawsze mamy wystarczającą introspekcję i potrzebujemy właściciela modułu, aby dostroił pewne zachowanie.
Shardable czy nie shardable?
Możliwe jest otagowanie modułu ( AndroidTest.xml ) za pomocą <option name="not-shardable" value="true" /> w celu powiadomienia wiązki, że nie powinna być shardowana.
W typowym module, pozwolenie shardowi wiązki na moduł (domyślne zachowanie) jest słuszne. Ale w niektórych przypadkach możesz chcieć zastąpić to zachowanie:
- Gdy konfiguracja twojego modułu jest droga:
Dzielenie modułu na fragmenty powoduje, że przygotowanie (zainstaluj pakiet APK, plik push itp.) może zostać uruchomione raz na urządzenie, którego dotyczy. Jeśli konfiguracja twojego modułu jest długa i kosztowna i nie warta replikacji w porównaniu do środowiska uruchomieniowego testu, powinieneś oznaczyć swój moduł jako niepodlegający shardingowi.
- Gdy liczba testów w Twoim module jest niska:
Sharding modułu powoduje, że wszystkie przypadki testowe mogą być wykonywane niezależnie na różnych urządzeniach. Odnosi się to do pierwszego punktu; jeśli twoja liczba testów jest niska, możesz skończyć z pojedynczym testem lub brakiem testu w niektórych fragmentach, co sprawiłoby, że każdy krok przygotowawczy byłby dość kosztowny. Na przykład zainstalowanie pakietu APK dla pojedynczego przypadku testowego zwykle nie jest tego warte.
Testy oprzyrządowania: Maksymalna liczba odłamków?
Test oprzyrządowania uruchomiony przez AndroidJUnitTest nie ujawnia w uprzęży, ile testów jest częścią oprzyrządowania, dopóki nie zainstalujemy i nie uruchomimy APK. Operacje te są kosztowne i nie można ich wykonać w czasie shardingu dla wszystkich modułów wchodzących w skład pakietu.
Uprząż może nadmiernie uszkodzić test oprzyrządowania i skończyć z kilkoma pustymi odłamkami; sharding test oprzyrządowania z pięcioma testami w sześciu shardach daje pięć shardów z jednym testem i jeden shard bez testów. Każdy z tych odłamków wymagałby kosztownej instalacji APK.
Tak więc, gdy liczba testów w pakiecie APK testu oprzyrządowania jest niska, oznaczanie modułu za pomocą <option name="not-shardable" value="true" /> pozwoliłoby wiązce wiedzieć, że fragmentowanie tego modułu nie jest tego warte.
Program AndroidJUnitTest ma specjalną opcję umożliwiającą określenie maksymalnej liczby fragmentów, na które można fragmentować: <option name="ajur-max-shard" value="5" /> .
Pozwala to określić maksymalną liczbę przypadków, gdy instrumentacja może zostać podzielona na fragmenty, niezależnie od liczby żądanych fragmentów na poziomie wywołania. Domyślnie Instrumentacja zostanie podzielona na liczbę fragmentów żądanych dla wywołania.
Na przykład, jeśli testowy pakiet APK oprzyrządowania zawiera tylko dwa przypadki testowe, ale nadal chcesz go podzielić, posiadanie wartości ajur-max-shard równej 2 zapewni, że nie tworzysz pustych fragmentów.