Android dziwne testy sharding

Question

Ja eksperymentuje z testu sharding na Androida i Dostaję dość dziwne wyniki:

+ adb -s emulator-5580 shell am instrument -e numShards 2 -e shardIndex 0 -e class com.package.etc.automation.Tests.SanityTest.SanityTest -w com.package.etc.test/android.support.test.runner.AndroidJUnitRunner 

com.package.etc.automation.Tests.SanityTest.SanityTest:.......... 

Time: 306.578 

OK (10 tests) 


+ adb -s emulator-5582 shell am instrument -e numShards 2 -e shardIndex 1 -e class com.package.etc.automation.Tests.SanityTest.SanityTest -w com.package.etc.test/android.support.test.runner.AndroidJUnitRunner 

com.package.etc.automation.Tests.SanityTest.SanityTest:...................... 

Time: 645.723 

OK (22 tests) 

Jak widać, adb podzielić na dwie nierówne testy grup. Drugi ma dwa razy więcej testów niż pierwszy i wykonuje dwa razy dłużej. Nie najlepsza paralelność, jeśli mnie pytasz.

Czy istnieje możliwość kontrolowania rozkładu testów, lub przynajmniej siła adb do równomiernego podziału testów?

Answer 1

Śledźmy to.

Kiedy zestaw testów to started, TestRequestBuilder jest zbudowany na JUnit Filters. ShardingFilter jest jednym z nich i is added. Dodanie go oznacza, że ​​poprzednio dodany Filter jest "intersected" z nowym - metoda jest wywoływana. Jeśli spojrzeć na to, co bardziej prawdopodobne w tym fragmencie:

if (description.isTest()) { 
    return (Math.abs(description.hashCode()) % mNumShards) == mShardIndex; 
} 

i zastępując numerów (numShards=2), można zauważyć, że jest to tylko test parzystości. Statystycznie może się zdarzyć, że wygenerowany rozkład parzystości HashCode nie wynosi 50%. Co więcej, gdy niektóre testy w klasie testowej są ignorowane, wyłączane i przeplatają się z włączonymi testami, można jeszcze bardziej przeszkadzać określonej metodzie(Junit Description generowany jest z nazwy metody i klasy).

To tylko statystyki. Jak można zobaczyć w this answer:

Jak są podzielone na grupy jest dowolna