Чтобы немного рассказать о себе, у нашей команды есть отдельный репозиторий E2E, в котором мы используем puppeteer для тестирования продукта, который мы создаем. Эти тесты E2E используют пользовательский интерфейс внешнего интерфейса, но поскольку для обеспечения правильного поведения задействовано несколько внутренних сервисов, мы решили поместить их все в отдельный репозиторий.
Мы обсуждаем одну философскую проблему внутренне ли мы должны требовать, чтобы наш набор тестов передавал конвейеры запросов на извлечение в репозиторий E2E или нет.
Основные моменты, по которым не требуется проходить тесты в PR:
- Тесты могут быть неудачными из-за ошибок в архитектуре, но это означает, что тест прошел хорошо и обнаружил ошибку, поэтому ее следует объединить с набором тестов.
- Запросы на извлечение в набор тестов E2E заблокированы и не может быть объединено, пока ошибки не будут исправлены. Запросы извлечения могут накапливаться или могут быть забыты.
- Тесты E2E, которые не объединены из-за блокировки из-за ошибок, не выполняются как часть плановых тестов periodi c, поэтому мы с меньшей вероятностью увидим проваленные тесты становятся зелеными без повторного запуска конвейеров PR вручную
Основные требования для прохождения тестов PR:
- Тесты должны пройти большинство времени. В случае сбоя конвейера E2E PR разработчики с большей вероятностью устранят ошибку, чтобы получить конвейер и объединить тесты.
- Если тесты E2E не выполняются в конвейере, разработчики не могут быть уверены, что тест когда-нибудь пройти Мы можем получить набор тестов в мастере, которые не являются действительными.
- Традиционный подход «Тест не пройден» -> «Тесты пройдены» -> «Рефакторинг» в TDD подразумевает, что мы написать тест и, если он потерпит неудачу, исправить это так, чтобы он был зеленым, а затем объединить его. Это гарантирует, что наши конвейеры всегда зеленые.
Что вы думаете? Какой правильный подход? Существуют ли какие-либо соответствующие ресурсы для создания наборов тестов для нескольких служб?