Спасибо за просмотр этой статьи. Обязательно ознакомьтесь с Частью 1 этого поста, где я сформулировал, что такое монорепозиторий и как оптимизировать этапы аутентификации, установки и сборки в жизненном цикле разработки. В этой статье я хотел бы поделиться тем, как протестировать изменения в отношении одного пакета / модуля в монорепозитории и создать единый отчет о покрытии для измененного пакета и загрузить его в Codecov, инструмент для сравнения отчетов о покрытии без получения ошибочных покрытие.

- ›Модульные тесты и покрытие кода. Модульные тесты являются предварительным условием для методологии экстремального программирования. Экстремальное программирование - это, по сути, стратегия «тестируйте все, что может сломать». На этапе активного кодирования очень полезно знать, будет ли когда-либо выполняться конкретная строка или вы можете ее удалить. Написание модульных тестов с помощью этой методологии упрощает разработку и рефакторинг кода, а также упрощает интеграцию функций.

Если вы работаете с приложениями JavaScript или TypeScript, скорее всего, вы уже знакомы с Jest, средой тестирования JavaScript, разработанной для обеспечения корректности любой кодовой базы JavaScript. Он позволяет вам писать тесты с доступным, знакомым и многофункциональным API, который быстро дает вам результаты. Он хорошо документирован и ориентирован на простоту. (Вы можете начать работу здесь!)

Jest предоставляет отчеты о покрытии кода прямо из коробки. Если у вас есть действующие модульные тесты, вы можете сразу получить метрики покрытия с помощью параметров покрытия Jest.

Если вы склонны устанавливать Jest локально в своем проекте в качестве зависимости, команда для получения покрытия может выглядеть так:

yarn jest --coverage

Если вы установили Jest глобально, следующая команда должна работать -

jest --coverage

Вы также можете получить подробный отчет о покрытии в формате HTML, используя следующую команду -

yarn jest --coverage --config='{ "coverageReporters": ["html"] }'

Все вышеупомянутые шаги отлично работают, когда вы запускаете и тестируете свой код локально. Но для того, чтобы вы гарантированно охватили каждую фиксацию, пулреквест или развертывание, нам необходимо интегрировать инструменты для группировки, объединения, архивирования и сравнения отчетов о покрытии.
Codecov дает нам действенное покрытие. идеи, когда и где они нам нужны, чтобы гарантировать, что мы отправляем качественный код.

Если вы работаете с монорепозиторием, каждый раз, когда вы вносите изменения, вы в конечном итоге запускаете все наборы тестов, присутствующие в моем монорепозитории, тем самым увеличивая общее время сборки.
Чтобы оптимизировать время сборки на этапах модульного тестирования и покрытия, вы можете выполнить следующие шаги:

1) Запустите набор тестов только для измененного пакета.
Jest предоставляет --changedSince параметр CLI, который позволяет запускать тесты, связанные с изменениями, начиная с предоставленной ветки или хэша фиксации.

yarn jest --changedSince=master

Вы также можете использовать --onlyChanged , но работает только в том случае, если вы сейчас запускаете тесты в репозитории git / hg и требует статического графа зависимостей.

Примечание. Если вы используете Jest версии ‹v26.0, то changedSince может работать не так, как ожидалось. Вот исправление ошибки, сделанное шутливым сообществом.

2) Сгенерировать отчет о покрытии только для измененного пакета.
Одной из важных функций, которые предоставляет codecov, являются Флаги и Флаги переноса для категоризации отчетов в едином репозитории.

- ›Флаги позволяют изолировать и классифицировать отчеты о покрытии для различных тестов и функций в вашем проекте. В частности, если вы используете установку монорепозитория, в которой вы хотите инкапсулировать тестовое покрытие каждого проекта независимо, флаги - отличный способ сделать это. Например, рассмотрим проект, скажем, Monorepo X с несколькими пакетами, как показано ниже -

Monorepo X     
   /component1
   /component2    
   /component3
   .
   .

Вы можете загружать отдельные отчеты о покрытии и отмечать их для каждого пакета в монорепозитории. Например, при запуске CI для проекта Monorepo X предположим, что покрытие для component1 записано в

tests/component1/output/coverage.xml

Затем этот отчет будет загружен следующим образом:

bash <(curl https://codecov.io/bash) -t <token> -f tests/Component1/output/coverage.xml -F component1

Передача параметра -F означает, что вы хотите загрузить отчет о покрытии в Codecov. -f указывает Codecov на запись в путь, по которому он идет.

Примечание -

  1. Флаги должны быть строчными, буквенно-цифровыми, точками или дефисами и содержать не более 45 символов.
  2. Вам нужно будет установить флажок для каждого загруженного отчета о покрытии. Не используйте несколько флагов в одном отчете. Вместо этого загрузите отчет дважды.
bash <(curl -s https://codecov.io/bash) -f tests/Component1/output/coverage.xml -F component1
bash <(curl -s https://codecov.io/bash) -f tests/Component2/output/coverage.xml -F component2

- ›Флаги переноса лучше всего использовать для монорепозиций с несколькими приложениями / языками и настройками итеративного / частичного / дельта-тестирования и т. Д. Если вы не тестируете весь свой код репо на при каждой фиксации Codecov использует функцию под названием «Флаги переноса», чтобы обновлять покрытие только для запущенных тестов. Флаги переноса на будущее создаются поверх основных флагов. Их можно использовать для любого проекта, который не загружает полное покрытие для каждой фиксации.

Вот как работают флаги переноса вперед -

1. Флаги переноса срабатывают для фиксации.

2. Если установлен флаг переноса на будущее, покрытие извлекается из предыдущего отчета о фиксации, который существует. Если отчеты о покрытии не загружены ранее, создается новый отчет, который загружается в codecov в первый раз.

3. Каждый раз при изменении покрытия создается новый отчет, который загружается в Codecov в качестве справки для будущих коммитов.

4. Если флаг переноса ложен, покрытие не переносится, а отчет о покрытии показывает 0% покрытия для непроверенных файлов.

Выявив измененные файлы и запустив наборы тестов для измененных проектов в монорепозитории, вы можете оптимизировать время, затрачиваемое на этап тестирования в конвейере сборки, что, в свою очередь, сокращает общее время сборки.

Ссылки -
https://docs.codecov.com/docs/about-code-coverage
https://jestjs.io/docs/cli