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, mit der Begründung für deren Verwendung.
Wenn eine Suite kontinuierlich im Labor ausgeführt wird, wird die Suite normalerweise auf mehrere Geräte verteilt, um die Gesamtfertigstellungszeit zu verkürzen. Der Kabelbaum versucht normalerweise, die Ausführungszeit jedes Shards auszugleichen, um die Gesamtfertigstellungszeit zu minimieren (wenn der letzte Shard fertig ist); aber aufgrund der Natur einiger Tests haben wir nicht immer genug Selbstbeobachtung und brauchen den Modulbesitzer, um ein Verhalten zu optimieren.
Shardfähig oder nicht Shardfähig?
Es ist möglich, ein Modul ( AndroidTest.xml ) mit <option name="not-shardable" value="true" /> zu taggen, um dem Kabelbaum mitzuteilen, dass es nicht geteilt werden soll.
In einem typischen Modul ist es das Richtige, den Kabelbaum Ihr Modul fragmentieren zu lassen (das Standardverhalten). In einigen Fällen möchten Sie dieses Verhalten jedoch möglicherweise überschreiben:
- Wenn die Einrichtung Ihres Moduls teuer ist:
Das Sharding eines Moduls führt dazu, dass die Vorbereitung (APK installieren, Datei pushen usw.) möglicherweise einmal pro beteiligtem Gerät ausgeführt wird. Wenn Ihr Modul-Setup langwierig und teuer ist und es im Vergleich zur Laufzeit des Tests nicht wert ist, repliziert zu werden, sollten Sie Ihr Modul als nicht-shardable kennzeichnen.
- Wenn die Anzahl der Tests in Ihrem Modul gering ist:
Das Teilen 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 der Tests gering ist, erhalten Sie möglicherweise einen einzelnen Test oder gar keinen Test in einigen Shards, was jeden Vorbereitungsschritt ziemlich teuer machen würde. Eine APK für einen einzelnen Testfall zu installieren lohnt sich beispielsweise meist nicht.
Instrumentierungstests: Maximale Anzahl von Shards?
Ein Instrumentierungstest, der über AndroidJUnitTest ausgeführt wird, zeigt dem Kabelbaum nicht, 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.
Das Geschirr könnte den Instrumententest übersharden und am Ende einige leere Splitter haben; 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 Markieren des Moduls mit <option name="not-shardable" value="true" /> dem Kabelbaum ermöglichen, zu wissen, 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 aufgeteilt werden darf: <option name="ajur-max-shard" value="5" /> .
Auf diese Weise können Sie angeben, wie oft die Instrumentierung maximal fragmentiert werden kann, unabhängig von der Anzahl der auf Aufrufebene angeforderten Shards. Standardmäßig wird die Instrumentierung in die für den Aufruf angeforderte Anzahl von Shards unterteilt.
Wenn Ihr Instrumentierungstest-APK beispielsweise nur zwei Testfälle enthält, Sie es aber trotzdem fragmentieren möchten, würde ein ajur-max-shard Wert von 2 sicherstellen, dass Sie keine leeren Shards erstellen.