Ответ.

Грамотное версионирование и интеграция автотестов критичны для обеспечения соответствия проверки актуальному состоянию проекта.

История вопроса

Автотесты поначалу часто вели отдельно от основного проекта, что приводило к несовместимостям и проблемам поддержки. Развитие нескольких веток, частые релизы ПО и тестов — породили необходимость общей системы контроля версий.

Проблема

Без версионирования и согласованной интеграции возникают:

Запуск неактуальных тестов на измененном ПО
"Поломки" тестов при выкатке нового функционала, не учитывающего изменений в тестах
Сбои в CI/CD

Решение

Современный подход:

Тесты хранятся в общей системе контроля версий (чаще всего git)
Привязка тестовой ветки к ветке разработки ПО: в feature-ветке — тесты и код идут вместе
Автоматические проверки/сборки проводятся по pull request'ам
Ревью и согласование изменений тестов и кода

# Общий подход:
git checkout -b feature/new_login
# Фича и тесты разрабатываются и тестируются вместе
# После ревью мерджатся вместе в основную ветку

Ключевые особенности:

Согласованность изменений кода и тестов (нет рассинхронизации)
Удобный откат и сопоставление версий (через git history)
Возможность командной работы и code review автотестов

Вопросы с подвохом.

Можно ли тесты хранить в отдельном (от кода проекта) репозитории?

Да, но тогда сложнее поддерживать актуальность тестов, требуется manual sync, есть риск "забыть" обновить что-то при релизе или багфиксе.

Должны ли тесты сразу покрывать весь новый функционал при создании PR?

Идеально — да, практически часто покрывают MVP/основные сценарии в первом PR, а сложные кейсы — отдельными задачами. Главное, чтобы критичный функционал был сразу покрыт.

Можно ли откатывать только тестовые изменения без отката кода?

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

Типовые ошибки и анти-паттерны

Хранение тестов не в git, а на файловых системах
Ведение тестов в отдельном репозитории без четкой связи с проектом
Вливание тестов снаружи (post factum), а не одновременно с кодом

Пример из жизни

Негативный кейс

Проект с отдельным репозиторием автотестов. После релиза программисты "забыли" обновить тесты — тесты падали, проходили неактуальные проверки, баги ловили на проде.

Плюсы:

Программисты могли работать независимо от QA

Минусы:

Потери времени на синхронизацию, наличие "устаревших" тестов

Позитивный кейс

Тесты и код проекта ведутся в одной git-ветке: при любом новом pull request обязательно обновляются автотесты для добавленного кода. Все изменения проходят code review и автоматические проверки.