Тесты и приложение находятся в разных репозиториях или вместе?
Что проверяют
Как устроен процесс в вашей команде и понимаете ли вы связь между расположением кода и синхронизацией версий. Вопрос звучит организационно, но за ним стоит инженерный: что происходит с тестами, когда приложение меняет контракт.
Как отвечать
Отвечайте по уровням тестов, для разных уровней ответ разный.
Юнит-тесты и интеграционные всегда лежат вместе с кодом: они правятся тем же коммитом и проходят на pull request. Вариантов тут нет.
Сквозные тесты на интерфейс и API бывают и так и так, и выбор объясняется просто:
- вместе с приложением: правка кода и правка теста едут одним коммитом, версия теста всегда соответствует версии приложения, откат возвращает согласованную пару, прогон идёт в том же пайплайне до мержа;
- отдельно: оправдано, когда тесты покрывают сразу несколько сервисов и принадлежат отдельной команде, когда у автотестов свой стек и своя сборка, или когда прогон идёт против общего стенда по расписанию.
Скажите, чем платите за раздельность: нужна явная привязка версий, иначе тесты либо проверяют не ту сборку, либо краснеют после каждого релиза. Обычно это тег или ветка в репозитории тестов под релиз и запуск по событию деплоя, а не по своему расписанию.
Хороший ответ заканчивается позицией: по умолчанию вместе, отдельно только для кросс-командных сценариев, и в любом случае прогон должен блокировать выкатку.
Где спотыкаются
Утверждают, что отдельный репозиторий упрощает CI/CD. Наоборот: появляется задача синхронизации версий и запуска чужого пайплайна, а автор изменения перестаёт видеть, что именно он сломал.
Второе: отвечают абстрактно, что всё зависит от проекта, и перечисляют плюсы и минусы обоих вариантов без своего опыта. Спрашивают, как работали именно вы, а не просят обзор подходов.
Третье: держат тесты отдельно и не блокируют релиз их результатом. Прогон, который никого не останавливает, за пару месяцев превращается в стену падений, на которую все перестают смотреть.