Auf dieser Seite wird beschrieben, was für ein Suite-Modul (AndroidTest.xml) über Sharding optimiert werden kann, um die beste Geschwindigkeit bei der kontinuierlichen Ausführung im Labor zu erzielen. Wir versuchen, die Optionen allgemein zu beschreiben und die Gründe für die Verwendung der einzelnen Optionen zu erläutern.
Wenn eine Suite im Lab kontinuierlich ausgeführt wird, wird sie in der Regel auf mehrere Geräte aufgeteilt, um die Gesamtdauer zu verkürzen. Normalerweise versucht das Harness, die Ausführungszeit der einzelnen Shards auszugleichen, um die Gesamtbearbeitungszeit (wenn der letzte Shard abgeschlossen ist) zu minimieren. Aufgrund der Art einiger Tests haben wir jedoch nicht immer genügend Introspektion und der Modulinhaber muss einige Verhaltensweisen anpassen.
Kann die Funktion in Shards aufgeteilt werden?
Es ist möglich, ein Modul (AndroidTest.xml) mit <option name="not-shardable" value="true" /> zu taggen, um den Harness darüber zu informieren, dass es nicht aufgeteilt werden soll.
In einem typischen Modul ist es sinnvoll, wenn das Harness Ihr Modul aufteilt (Standardverhalten). In einigen Fällen möchten Sie dieses Verhalten jedoch möglicherweise überschreiben:
- Wenn die Einrichtung Ihres Moduls teuer ist:
Wenn Sie ein Modul aufteilen, wird die Vorbereitung (APK installieren, Datei übertragen usw.) möglicherweise einmal pro Gerät ausgeführt. Wenn die Einrichtung Ihres Moduls lange dauert und teuer ist und sich im Vergleich zur Laufzeit des Tests nicht lohnt, es zu replizieren, sollten Sie Ihr Modul als nicht partitionierbar kennzeichnen.
- Wenn die Anzahl der Tests in Ihrem Modul gering ist:
Wenn Sie ein Modul aufteilen, werden alle Testläufe möglicherweise unabhängig voneinander auf verschiedenen Geräten ausgeführt. Das hängt mit dem ersten Punkt zusammen: Wenn die Anzahl der Tests gering ist, kann es sein, dass in einigen Shards nur ein Test oder gar kein Test ausgeführt wird. In diesem Fall wäre jeder Vorbereitungsschritt sehr aufwendig. Die Installation einer APK für einen einzelnen Testlauf lohnt sich in der Regel nicht.
Instrumentierungstests: Maximale Anzahl an Shards?
Bei einem Instrumentationstest, der über AndroidJUnitTest ausgeführt wird, wird dem Harness erst nach der Installation und Ausführung des APK mitgeteilt, wie viele Tests Teil der Instrumentation sind. Diese Vorgänge sind kostspielig und können nicht zum Zeitpunkt des Shardings für alle Module der Suite ausgeführt werden.
Das Harness kann den Instrumentationstest übermäßig aufteilen, sodass einige leere Shards entstehen. Wenn Sie einen Instrumentationstest mit fünf Tests in sechs Shards aufteilen, erhalten Sie fünf Shards mit einem Test und einen Shard ohne Tests. Für jeden dieser Shards wäre eine kostspielige APK-Installation erforderlich.
Wenn die Anzahl der Tests im Instrumentationstest-APK gering ist, kann das Modul mit <option name="not-shardable" value="true" /> getaggt werden, damit das Harness weiß, dass sich das Sharding dieses Moduls nicht lohnt.
Für den AndroidJUnitTest-Runner gibt es eine spezielle Option, mit der die maximale Anzahl von Shards angegeben werden kann, in die er aufgeteilt werden darf: <option name="ajur-max-shard" value="5" />.
So können Sie eine maximale Anzahl von Shards für die Instrumentierung angeben, unabhängig von der Anzahl der Shards, die auf Aufrufebene angefordert werden. Standardmäßig wird die Instrumentierung in die Anzahl der Shards aufgeteilt, die für den Aufruf angefordert wurden.
Wenn Ihr APK für Instrumentierungstests beispielsweise nur zwei Testläufe enthält, Sie es aber trotzdem sharden möchten, sorgt ein ajur-max-shard-Wert von 2 dafür, dass keine leeren Shards erstellt werden.