На этой странице описывается, как можно настроить модуль набора ( AndroidTest.xml ) с помощью шардинга, чтобы добиться максимальной скорости при непрерывном выполнении в лабораторных условиях. Мы постараемся описать все варианты в общем виде, приведя обоснование использования каждого из них.
При непрерывном запуске набора тестов в лаборатории он обычно распределяется по нескольким устройствам для сокращения общего времени выполнения. Система обычно пытается сбалансировать время выполнения каждого набора тестов, чтобы минимизировать общее время выполнения (по завершении последнего набора тестов); но из-за особенностей некоторых тестов нам не всегда хватает интроспекции, и требуется, чтобы владелец модуля настроил некоторые параметры поведения.
Шардируемый или нет?
Можно пометить модуль ( AndroidTest.xml ) тегом <option name="not-shardable" value="true" /> чтобы уведомить систему о том, что его не следует шардировать.
В типичном модуле правильным решением будет позволить системе Harvest шардировать ваш модуль (поведение по умолчанию). Но в некоторых случаях может потребоваться переопределить это поведение:
- Если настройка вашего модуля требует больших затрат:
Шардинг модуля приводит к необходимости подготовки (установки APK, отправки файла и т. д.), которая, возможно, будет выполнена один раз для каждого устройства. Если настройка модуля занимает много времени и требует больших затрат, а её воспроизведение нецелесообразно по сравнению со временем выполнения теста, следует пометить модуль как нешардируемый.
- Если количество тестов в вашем модуле невелико:
Шардинг модуля приводит к тому, что все тестовые случаи, возможно, будут выполняться независимо на разных устройствах. Это относится к первому пункту: если количество тестов невелико, в некоторых шардах может оказаться всего один тест или вообще не быть ни одного, что значительно увеличит затраты на подготовку. Например, установка APK-файла для одного тестового случая обычно нецелесообразна.
Инструментальные испытания: Максимальное количество осколков?
Тест инструментирования, выполняемый через AndroidJUnitTest , не показывает системе, сколько тестов входит в инструментирование, пока мы не установим и не запустим APK. Эти операции требуют больших затрат и не могут быть выполнены во время шардинга для всех модулей пакета.
Система может чрезмерно разбить инструментальный тест на шарды и в результате получить несколько пустых шардов; шардинг инструментального теста с пятью тестами в шести шардах приведёт к пяти шардам с одним тестом и одному шарду без тестов. Каждый из таких шардов потребует дорогостоящей установки APK.
Таким образом, если количество тестов в APK-файле инструментального теста невелико, то маркировка модуля с помощью <option name="not-shardable" value="true" /> позволит системе управления понять, что шардинг этого модуля нецелесообразен.
У средства AndroidJUnitTest есть специальная опция, позволяющая указать максимальное количество шардов, на которые разрешено разделять тест: <option name="ajur-max-shard" value="5" /> .
Это позволяет указать максимальное количество раз, которое инструментирование может быть сегментировано, независимо от количества сегментов, запрошенных на уровне вызова. По умолчанию инструментирование будет сегментировано на количество сегментов, запрошенных для вызова.
Например, если ваш APK-файл инструментального теста содержит только два тестовых случая, но вы все равно хотите его сегментировать, то значение ajur-max-shard равное 2 , гарантирует, что вы не создаете пустые сегменты.