Ниже приведены некоторые типичные формы автоматизации, которые вы, возможно, захотите использовать в своей системе CI.
Основные вакансии
Сборка. Создавая проект с нуля, вы гарантируете, что новые изменения компилируются правильно и что все библиотеки и инструменты совместимы друг с другом.
Проверка стиля или проверка: это необязательный, но рекомендуемый шаг. Когда вы применяете правила стиля и выполняете статический анализ , проверки кода могут быть более краткими и целенаправленными.
Локальные тесты или тесты на стороне хоста : они запускаются на локальном компьютере, на котором выполняется сборка. В Android это обычно JVM, поэтому они быстрые и надежные. Они также включают робоэлектрические тесты.
Инструментальные испытания
Тесты, выполняемые на эмуляторах или физических устройствах, требуют некоторой подготовки, ожидания загрузки или подключения устройств, а также других операций, которые усложняют работу.
Существует несколько вариантов запуска инструментальных тестов на CI:
- Управляемые устройства Gradle можно использовать для определения используемых устройств (например, «Эмулятор Pixel 2 на API 27»), и он управляет подготовкой устройств.
- Большинство систем CI поставляются со сторонним плагином (также называемым «действием», «интеграцией» или «шагом») для работы с эмуляторами Android.
- Делегируйте инструментальные тесты ферме устройств, например Firebase Test Lab . Фермы устройств используются из-за их высокой надежности и могут работать на эмуляторах или физических устройствах.
Регрессионные тесты производительности
Для мониторинга производительности приложения мы рекомендуем использовать библиотеки тестов . Для автоматизации тестов производительности во время разработки требуются физические устройства, обеспечивающие согласованные и реалистичные результаты тестов.
Выполнение тестов может занять много времени, особенно если у вас большой охват кода и действий пользователей, которые вы тестируете. Вместо того, чтобы запускать все тесты для каждой объединенной функции или фиксации, рассмотрите возможность их выполнения как часть регулярной плановой сборки обслуживания, например ночной сборки.
Мониторинг производительности
Вы можете отслеживать снижение производительности с помощью пошаговой подгонки . Пошаговая подгонка определяет скользящее окно результатов предыдущей сборки, которые вы сравниваете с текущей сборкой. Этот подход объединяет несколько результатов тестов в одну метрику, специфичную для регрессии. Вы можете применить пошаговую подгонку, чтобы уменьшить шум во время регрессионного тестирования.
Это уменьшает количество ложных срабатываний, которые могут возникнуть, когда время тестирования для одной сборки медленное, а затем снова нормализуется.
Регрессионные проверки тестового покрытия
Покрытие тестами — это показатель, который может помочь вам и вашей команде решить, достаточно ли тесты покрывают изменение. Однако это не должно быть единственным показателем. Обычной практикой является настройка регрессионной проверки, которая завершается неудачно или выдает предупреждение, когда покрытие снижается относительно базовой ветви.
,Ниже приведены некоторые типичные формы автоматизации, которые вы, возможно, захотите использовать в своей системе CI.
Основные вакансии
Сборка. Создавая проект с нуля, вы гарантируете, что новые изменения компилируются правильно и что все библиотеки и инструменты совместимы друг с другом.
Проверка стиля или проверка: это необязательный, но рекомендуемый шаг. Когда вы применяете правила стиля и выполняете статический анализ , проверки кода могут быть более краткими и целенаправленными.
Локальные тесты или тесты на стороне хоста : они запускаются на локальном компьютере, на котором выполняется сборка. В Android это обычно JVM, поэтому они быстрые и надежные. Они также включают робоэлектрические тесты.
Инструментальные испытания
Тесты, выполняемые на эмуляторах или физических устройствах, требуют некоторой подготовки, ожидания загрузки или подключения устройств, а также других операций, которые усложняют работу.
Существует несколько вариантов запуска инструментальных тестов на CI:
- Управляемые устройства Gradle можно использовать для определения используемых устройств (например, «Эмулятор Pixel 2 на API 27»), и он управляет подготовкой устройств.
- Большинство систем CI поставляются со сторонним плагином (также называемым «действием», «интеграцией» или «шагом») для работы с эмуляторами Android.
- Делегируйте инструментальные тесты ферме устройств, например Firebase Test Lab . Фермы устройств используются из-за их высокой надежности и могут работать на эмуляторах или физических устройствах.
Регрессионные тесты производительности
Для мониторинга производительности приложения мы рекомендуем использовать библиотеки тестов . Для автоматизации тестов производительности во время разработки требуются физические устройства, обеспечивающие согласованные и реалистичные результаты тестов.
Выполнение тестов может занять много времени, особенно если у вас большой охват кода и действий пользователей, которые вы тестируете. Вместо того, чтобы запускать все тесты для каждой объединенной функции или фиксации, рассмотрите возможность их выполнения в рамках регулярной плановой сборки обслуживания, например ночной сборки.
Мониторинг производительности
Вы можете отслеживать снижение производительности с помощью пошаговой подгонки . Поэтапная подгонка определяет скользящее окно результатов предыдущей сборки, которые вы сравниваете с текущей сборкой. Этот подход объединяет несколько результатов тестов в одну метрику, специфичную для регрессии. Вы можете применить пошаговую подгонку, чтобы уменьшить шум во время регрессионного тестирования.
Это уменьшает количество ложных срабатываний, которые могут возникнуть, когда время тестирования для одной сборки медленное, а затем снова нормализуется.
Регрессионные проверки тестового покрытия
Покрытие тестами — это показатель, который может помочь вам и вашей команде решить, достаточно ли тесты покрывают изменение. Однако это не должно быть единственным показателем. Обычной практикой является настройка регрессионной проверки, которая завершается неудачно или выдает предупреждение, когда покрытие снижается относительно базовой ветви.