Auf dieser Seite wird beschrieben, was Sie für ein Suite-Modul (AndroidTest.xml) über das Sharding optimieren können, um bei der kontinuierlichen Ausführung im Lab die beste Geschwindigkeit zu erzielen. Wir versuchen, die Optionen allgemein zu beschreiben und die Gründe für ihre Verwendung anzugeben.
Wenn eine Suite im Lab kontinuierlich ausgeführt wird, wird sie in der Regel auf mehrere Geräte verteilt, um die Gesamtzeit bis zum Abschluss zu verkürzen. Der Harness versucht in der Regel, die Ausführungszeit jedes Shards auszugleichen, um die Gesamtausführungszeit (wenn der letzte Shard fertig ist) zu minimieren. Aufgrund der Art einiger Tests haben wir jedoch nicht immer genügend Informationen und müssen den Modulinhaber bitten, einige Verhaltensweisen anzupassen.
Kann er partitioniert werden oder nicht?
Sie können ein Modul (AndroidTest.xml) mit <option name="not-shardable" value="true" /> taggen, um den Harness zu informieren, dass es nicht geShardet werden soll.
Bei einem typischen Modul ist es am besten, das Modul vom Harness schardern zu lassen (Standardverhalten). In einigen Fällen möchten Sie dieses Verhalten jedoch überschreiben:
- Wenn die Einrichtung Ihres Moduls teuer ist:
Wenn Sie ein Modul in Shards aufteilen, wird die Vorbereitung (APK installieren, Datei pushen usw.) möglicherweise einmal pro beteiligtem Gerät ausgeführt. Wenn die Moduleinrichtung lang und teuer ist und sich im Vergleich zur Laufzeit des Tests nicht lohnt, sollten Sie das Modul als nicht shardbar taggen.
- Wenn die Anzahl der Tests in Ihrem Modul gering ist:
Wenn Sie ein Modul in Shards aufteilen, werden alle Testfälle 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 vorhanden ist. Das würde jeden Vorbereitungsschritt ziemlich teuer machen. Die Installation eines APKs für einen einzelnen Testfall lohnt sich beispielsweise in der Regel nicht.
Instrumentierungstests: Maximale Anzahl von Shards?
Bei einem Instrumentierungstest, der über AndroidJUnitTest ausgeführt wird, wird dem Harness erst bei der Installation und Ausführung des APKs mitgeteilt, wie viele Tests Teil der Instrumentierung 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 Instrumentierungstest zu stark sharden und einige leere Shards erzeugen. Wenn Sie einen Instrumentierungstest mit fünf Tests in sechs Shards sharden, 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 Instrumentierungstest-APK also niedrig ist, kann das Modul mit <option name="not-shardable" value="true" /> getaggt werden, damit das Harness weiß, dass das Sharding dieses Moduls nicht sinnvoll ist.
Der AndroidJUnitTest-Ausführer hat eine spezielle Option, mit der die maximale Anzahl von Shards angegeben werden kann, in die er gesplittet werden darf: <option name="ajur-max-shard" value="5" />.
So können Sie unabhängig von der Anzahl der auf Aufrufebene angeforderten Shards eine maximale Anzahl von Shards für die Instrumentierung angeben. Standardmäßig wird die Instrumentierung in die Anzahl der für die Aufrufe angeforderten Shards aufgeteilt.
Wenn Ihr Instrumentierungstest-APK beispielsweise nur zwei Testfälle enthält, Sie es aber trotzdem in Shards aufteilen möchten, können Sie mit einem ajur-max-shard-Wert von 2 verhindern, dass leere Shards erstellt werden.