Auf dieser Seite wird beschrieben, was möglich ist, um ein Suite-Modul ( AndroidTest.xml ) über Sharding zu optimieren und die beste Geschwindigkeitsleistung während der kontinuierlichen Ausführung im Labor zu erzielen. Wir werden versuchen, die Optionen allgemein zu beschreiben und die Gründe für ihre Verwendung anzugeben.
Wenn eine Suite im Labor kontinuierlich ausgeführt wird, wird die Suite normalerweise auf mehrere Geräte verteilt, um die Gesamtfertigstellungszeit zu verkürzen. Der Harness versucht normalerweise, die Ausführungszeit jedes Shards auszugleichen, um die Gesamtabschlusszeit (wenn der letzte Shard fertig ist) zu minimieren. Aber aufgrund der Art einiger Tests verfügen wir nicht immer über genügend Selbstbeobachtung und müssen das Verhalten des Modulbesitzers anpassen.
Zersplitterbar oder nicht zersplitterbar?
Es ist möglich, ein Modul ( AndroidTest.xml ) mit <option name="not-shardable" value="true" /> zu kennzeichnen, um dem Harness mitzuteilen, dass es nicht fragmentiert werden soll.
In einem typischen Modul ist es richtig, den Kabelbaum Ihr Modul teilen zu lassen (das Standardverhalten). In einigen Fällen möchten Sie dieses Verhalten jedoch möglicherweise außer Kraft setzen:
- Wenn der Aufbau Ihres Moduls teuer ist:
Das Sharding eines Moduls führt dazu, dass die Vorbereitung (APK installieren, Datei pushen usw.) möglicherweise einmal pro betroffenem Gerät ausgeführt wird. Wenn die Einrichtung Ihres Moduls langwierig und teuer ist und es sich im Vergleich zur Testlaufzeit nicht lohnt, repliziert zu werden, sollten Sie Ihr Modul als nicht shardbar kennzeichnen.
- Wenn die Anzahl der Tests in Ihrem Modul gering ist:
Das Sharding eines Moduls führt dazu, dass alle Testfälle möglicherweise unabhängig voneinander auf verschiedenen Geräten ausgeführt werden. Dies bezieht sich auf den ersten Punkt; Wenn die Anzahl Ihrer Tests gering ist, kann es sein, dass Sie in einigen Shards nur einen oder keinen Test haben, was jeden Vorbereitungsschritt ziemlich teuer machen würde. Beispielsweise lohnt sich die Installation einer APK für einen einzelnen Testfall meist nicht.
Instrumentierungstests: Maximale Anzahl Shards?
Ein Instrumentierungstest, der über AndroidJUnitTest ausgeführt wird, zeigt dem Kabelbaum nicht an, wie viele Tests Teil der Instrumentierung sind, bis wir das APK tatsächlich installieren und ausführen. Diese Vorgänge sind kostspielig und können nicht zur Sharding-Zeit für alle Module der Suite ausgeführt werden.
Der Kabelbaum könnte den Instrumentierungstest überfordern und am Ende einige leere Splitter aufweisen. Das Sharding eines Instrumentierungstests mit fünf Tests in sechs Shards führt zu fünf Shards mit einem Test und einem Shard ohne Tests. Jeder dieser Shards würde eine kostspielige APK-Installation erfordern.
Wenn also die Anzahl der Tests im Instrumentierungstest-APK gering ist, würde das Taggen des Moduls mit <option name="not-shardable" value="true" /> dem Harness ermöglichen, zu erkennen, dass sich das Sharding dieses Moduls nicht lohnt.
Der AndroidJUnitTest Runner verfügt über eine spezielle Option, mit der er die maximale Anzahl von Shards angeben kann, in die er fragmentieren darf: <option name="ajur-max-shard" value="5" /> .
Dadurch können Sie eine maximale Anzahl von Shards für die Instrumentierung angeben, unabhängig von der Anzahl der auf der Aufrufebene angeforderten Shards. Standardmäßig wird die Instrumentierung in die Anzahl der für den Aufruf angeforderten Shards aufgeteilt.
Wenn Ihr Instrumentierungstest-APK beispielsweise nur zwei Testfälle enthält, Sie es aber dennoch teilen möchten, stellt ein ajur-max-shard Wert von 2 sicher, dass Sie keine leeren Shards erstellen.