старый и новый, старый не будет обновляться, новый пишут ему на замену. Для какого из них нужно писать автотесты?
Собеседующие считали, что для старого. Аргумент был прост - он не обновляется, поэтому тесты не придется постоянно переделывать.
Мой ответ - для нового. Аргументы от обратного, т.е. для старого тесты даже при идеальной реализации не понадобятся (точнее не принесут никакой пользы). Ведь обновлений кода нет, поэтому регрессий тоже нет, а косяки инфрастуктуры отслеживаются более специфичными инструментами.
Более того, в условиях не было деталей разработки. Это значит что при TDD ответ очевиден. А при переносе старого бэкенда можно сделать стабильные апи тесты.
Ну и наконец компромиссный вариант для наихудшего сценария, когда фронт постоянно меняют - можно заранее подготовить фикстуры, продумать общую логику, расставить testid.
Ваше мнение?
собеседующие просто немного ушли в крайность по подходу "стабильное покрывать разумнее" , ну и тут контекста не хватает. Обновление не предусмотрено НЕ РАВНО отсутствие необходимости регресса минимального) какие бы крутышки не были разработчики. задеть что угодно где угодно - это их навык по умолчанию)) Поэтому не стоит зарекаться. А вообще ответ всегда один - ROI посчитали и выбрали. все. это работает всегда. ROI объективно
У меня пока только один вопрос: Причём тут вообще TDD?
Обсуждают сегодня