Автор: Леонид Хусидман (Leonid Khudisman)
Оригинал статьи
Перевод: Ольга Алифанова

Где должен жить код тестов проекта? Старый, как мир, спор

Как только инженерное сообщество начало включать тестирование в жизненный цикл разработки ПО, мы спорим о подходящем доме для кода тест-автоматизации. Должен ли он жить в том же репозитории, что и код тестируемого приложения? Может, лучше выделить его в отдельный репозиторий, подальше от основной базы кода? Этот спор почти так же горяч, как противостояние «табуляция или пробелы».

В этой статье изложены аргументы обеих сторон, а также плюсы и минусы каждого подхода. Она предлагает гибридное решение на основании опыта автора и обсуждений с командой разработки. Статья делает акцент на важности «культуры качества» и роли адвокатов качества, которую играют инженеры по обеспечению качества. Также будет обсуждаться внедрение прекоммитных хуков и использование тегов в pytest для создания быстрой петли обратной связи и повышения эффективности непрерывной интеграции и поставки/разработки (CI/CD). В заключении говорится о том, что для улучшения QA-практик необходимы масштабные исследования.

О чем спор?

Кто эти современные Хэтфилды и МакКои? Давайте посмотрим на обе группы повнимательнее. Для ясности я не буду обсуждать связанное с нашим вопросом противостояние, писать код тестов на том же языке, что и приложение, или не писать. Оставим это на другой раз.

Адвокаты репозитория приложения говорят, что так проще поддерживать код тестов

Адвокаты репозитория приложения твердо уверены, что все, что относится к коду приложения, должно существовать в этом же коде. Это включает юнит-тестирование, а также любую тест-автоматизацию. Решение часто принимается на основании используемого тест-фреймворка, а идея в том, что код тест-автоматизации легче поддерживать, если он часть репозитория приложения.

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

Адвокаты отдельного репозитория принимают во внимание сложность проекта тест-автоматизации и уверены, что в репозитории приложения должно находиться только само приложение.

Лучший источник информации – метод проб и ошибок

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

Погрузимся глубже в «за» и «против» хранения кода тестов в репозитории приложения или же в отдельном репозитории.

Преимущества и недостатки каждого подхода

Преимущества использования репозитория приложения

• Хранение кода автоматизации в репозитории приложения дает возможность убедиться, что тесты всегда синхронизированы с последними изменениями кода приложения.
• Все могут отслеживать изменения как в приложении, так и в тестах, через единый репозиторий.
• Пайплайнам CI/CD проще получить доступ к тестам и запускать их вместе с билдами кода приложения.
• Улучшение сотрудничества между разработчиками и QA, развитие коммуникации, общая ответственность за качество.
• Код приложения и тестов делит единое окружение.
• Изменения в коде приложения можно немедленно проверить, не переключаясь между репозиториями.
• Снижение затрат на техническое обслуживание, так как репозиторий только один.
• Разработчики и QA могут проводить ревью кода друг друга.
• Общими зависимостями можно централизованно управлять.
• Упрощение дебага падений тестов.
• Комбинация кода приложения и тестов может замусорить репозиторий, в нем становится сложно ориентироваться.
• Чем больше кода в одном репозитории, тем выше шанс конфликтов слияния.
• Запуск тестов в том же пайплайне может замедлить билд, особенно при большом наборе тестов.
• Код тестов может демаскировать секретные данные или внутренние API, доступа к которым из основной базы кода быть не должно.
• Хранение кода тестов в репозитории приложения может ограничить возможность использования этих тестов в других проектах или приложениях.
• Разработчики могут меньше концентрироваться на создании и поддержке высококачественного кода тестов, если он смешан с кодом приложения, и это может привести к потенциальному игнорированию практик тестирования.
• По мере роста проекта единый репозиторий для кода и приложения, и тестов может стать громоздким и сложным в управлении.
• Смешивание кода тестов и приложения может размыть границы между ответственностью тестирования и разработки.
• Управление зависимостями кода приложения и тестов в одном репозитории может привести к конфликтам и повышению сложности.
• Различным командам могут понадобиться различные уровни доступа, а когда в одном репозитории хранится и приложение, и тесты, это затрудняет управление доступами.
• Если репозиторий сконцентрирован только на коде приложения, в нем проще ориентироваться, им проще управлять.
• Код тестирования может версионироваться независимо от кода приложения.
• Отдельный репозиторий для кода тестов упрощает использование тестов в других проектах.
• Для репозитория с кодом тестов можно настроить отдельные права доступа, разрешив только конкретным членам команды изменять этот код.
• Для репозитория кода тестов можно настроить отдельные пайплайны CI/CD, и процессы тестирования будут более специализированными и оптимизированными.
• Снижение размера репозитория кода приложения за счет отделения кода тестов.
• Отделение кода приложения от кода тестов упрощает управление проектом и понимание его частей.
• Специфичными для тестирования зависимостями можно независимо управлять, избегая потенциальных конфликтов с зависимостями приложения.
• Команды могут работать над кодом тестов, не затрагивая код приложения, то есть параллельно проводить разработку и тестирование.
• Отдельный репозиторий для кода тестов упрощает масштабирование тестирования.
• Сложная синхронизация кода тестов с изменениями кода приложения.
• Поддержание версий кода тестов в соответствии с версиями кода приложения может быть затруднено.
• Изменения кода приложения могут не сразу отразиться на тестах, потенциально замедляя обнаружение проблем.
• Разработчикам и QA сложнее сотрудничать.
• Интеграция тестов из отдельного репозитория в пайплайны CI/CD может быть сложнее и потребовать дополнительной конфигурации.
• Управление двумя отдельными репозиториями требует больше усилий и времени на поддержку.
• Ревью изменений в обоих репозиториях может быть длительнее и сложнее.
• Общие ресурсы или утилиты, возможно, нужно дублировать между репозиториями.
• Понижается видимость кода тестов для разработчиков, что потенциально приводит к разрыву между разработкой и тестированием.
• Новичкам команды нужно настроить и разобраться в двух разных репозиториях, что усложняет обучение.

Недостатки использования репозитория приложения

Преимущества использования отдельного репозитория

Недостатки использования отдельного репозитория

Представляю вам гибридное решение вопроса репозиториев

Ух. Хорошие аргументы с обеих сторон. Неудивительно, что этот спор так и не решен.

Я могу предоставить компромиссное решение, которое может сработать для множества организаций. Зачем выбирать один-единственный подход, если в реальности наилучшим будет гибридный? Я основываю свое предложение на личном опыте и моих многолетних разговорах с членами команды как со стороны разработки, так и со стороны QA.

Тест-план похож на пахлаву – в нем множество слоев, он тщательно сконструирован, и если все правильно сделано – о, эта сладость успеха! ��

Какой код должен жить в репозитории приложения?

Юнит-тесты принадлежат репозиторию приложения

По моему личному опыту и словам других участников QA-сообщества, лучшим домом для юнит-тестов будет репозиторий приложения. Не думаю, что кто-то будет спорить, что юнит-тесты должны жить где-то снаружи в своем личном репозитории.

Контрактные тесты лучше работают в репозитории приложения

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

В норме я бы поспорил, что интеграционное тестирование должно жить вовне репозитория приложения, и я обосную это чуть позже. Однако контрактное тестирование – особый вид интеграционного тестирования. Это наилучший способ убедиться, что сервисы могут правильно общаться друг с другом, без лишних затрат на полноценные end-to-end тесты.

Оснащение тестов в репозитории приложения

Я бы добавил и юнит, и контрактные тесты в прекоммитный хук вместе с инструментами контроля качества кода, его статического анализа и проверки безопасности. Эта практика дает разработчикам быструю обратную связь и помогает убедиться, что пулл-реквесты соответствуют нужным процессам.

Какой код должен жить в репозитории кода тестов?

Если вкратце: все остальные тесты!

Я считаю, что все остальные типы тестов должны жить вне репозитория приложения, в своем личном репозитории.

Сделайте шаг назад и подумайте – зачем нам нужны различные уровни тестирования? Каких результатов мы хотим добиться?

Добавьте в репозиторий кода тестов инфраструктуру и ограничьте имитирование

Планируя такое тестирование, как интеграционное, функциональное, доступности, end-to-end, надо добавить инфраструктуру в качестве тестируемого компонента и максимально сократить имитирование.

Группировка тестов в репозитории тестов с тегами pycode

Я твердо верю в принцип DRY (не повторяйся), и думаю, что имеет смысл хранить код тест-автоматизации в едином репозитории, чтобы снизить дупликацию кода и логики – это улучшает поддерживаемость и снижает ошибки.

Нужно использовать нечто вроде «тегов» в pytest для группировки релевантных тестов в наборы тестов. Эти наборы затем можно использовать в пайплайне CI/CD.

В пайплайне CI/CD, когда прекоммитный хук успешно пройден, а пулл-реквест готов к созданию, нужно начать добавлять слои тестирования, используя вышеупомянутые теги наборов тестов. В этом случае вам нужно создать доступ только к одному репозиторию кода тестов, а затем прогнать релевантные тесты.

Уведомление нужных людей о падениях тестов

Последним поводом для волнения хорошего адвоката QA будет проверка, что команда быстро узнает о падениях, что данные видимы. К сожалению, по моему и не только опыту, после запуска пайплайна CI/CD никто не отслеживает его завершение. Нам надо убедиться, что мы даем быструю обратную связь и уведомить нужных людей, если произошло падение. Надо также собирать исторические данные для отслеживания трендов и выявления возможностей для улучшения.

Вкратце о гибридном подходе к репозиторию

Наше исследование тест-стратегий выявило важность всеобъемлющего подхода к проверке качества и надежности ПО. Каждый шаг, от прекоммитных хуков до пайплайнов CI/CD, от юнит-тестирования до тестирования безопасности, играет критическую роль в тестировании. Ниже – таблица, резюмирующая ключевые компоненты этого процесса и делающая упор на необходимости дальнейших исследований и стандартизации сообщества QA.

Таблица 1: Типы тестирования и подходяще оснащение для репозиториев кода приложения и кода тестов

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

Заключение

Спор о том, какой репозиторий лучше, продолжается, но гибридный подход – это практичное компромиссное решение этого спора. Сохраняя юнит-тесты и контрактные тесты в репозитории приложения, и отделяя другие тесты в отдельный репозиторий, команды получают преимущества обоих подходов. Эта стратегия поддерживает культуру качества и упрощает сдвиг тестирования влево, что в итоге приводит к более эффективным и результативным процессам разработки ПО.

Обсудить в форуме