Как предотвратить дублирование и ломку общих методов в тестах при работе нескольких тестировщиков?
Что проверяют
Умеете ли вы организовать общий код автотестов так, чтобы он рос вместе с командой и не ломался от чужих правок. Интервьюеру важны механизмы, а не договорённости на словах. Следом просят пример из вашей практики.
Как отвечать
Опишите слои фреймворка и правила вокруг них:
- слоистая структура: тесты вызывают бизнес-шаги (
loginAs,createOrder), шаги опираются на Page Object или API-клиенты, ниже лежит ядро с драйвером, конфигом и ожиданиями. Дубли чаще всего появляются, когда слоя шагов нет и каждый пишет логин заново; - владельцы общего кода: каталог
coreзакреплён вCODEOWNERS, правки туда проходят обязательное ревью владельца; - CI на каждый пулл-реквест: правка общего метода прогоняет зависящие тесты до слияния, а не на ночном прогоне;
- тесты на сам фреймворк: у сложных хелперов свои юнит-тесты;
- совместимость: сигнатуру общего метода не меняют ради одного теста. Добавляют параметр со значением по умолчанию или новый метод, а старый помечают
@Deprecated(в Python черезwarnings.warn) и убирают после миграции; - поиск дублей: каталог хелперов в README, детектор копипасты в SonarQube или PMD CPD.
Вопрос поведенческий, поэтому опирайтесь на свой опыт: какая была проблема, что вы внедрили, что изменилось. Нужны свои цифры: сколько тестов падало после правок в общем коде, как быстро это стали ловить. Если опыта нет, так и скажите и расскажите, как устроили бы процесс, опираясь на то, что видели в команде или в открытых проектах.
Где спотыкаются
Отвечают «договоримся писать аккуратно». Без ревью владельцев и CI на пулл-реквестах такая договорённость живёт до первого дедлайна.
Доводят DRY до крайности. Хелпер с пятью булевыми флагами хуже двух похожих методов, а тест, где всё спрятано в общих функциях, невозможно прочитать. В тестах читаемость важнее отсутствия повторов.
Прячут проверки внутрь общих методов. Метод берут в чужой сценарий, где эта проверка не нужна, и тест падает не по той причине.