На чем руководствоваться при написании автотестов?
Что проверяют
Понимаете ли вы, что автоматизировать нужно не всё подряд, и есть ли у вас критерий отбора. Заодно проверяют, отличаете ли вы «написать тест» от «поддерживать набор тестов год», потому что вторая задача дороже первой.
Как отвечать
Разложите ответ на три уровня.
Что автоматизировать: сценарий прогоняется часто, требования к нему устойчивы, ручная проверка дорогая, поломка больно бьёт по бизнесу. Разовая проверка и функциональность, которая переписывается каждый спринт, в автоматизацию не окупаются.
На каком уровне: на самом низком, где проверка остаётся осмысленной. Бизнес-правило проверяется юнит-тестом или запросом к API, через интерфейс идёт только то, что без интерфейса не проверить.
Каким должен быть тест: независимым и работающим в любом порядке, готовящим свои данные через API или фикстуры и убирающим их за собой, с одной проверкой смысла на тест, с понятным именем и внятным сообщением при падении. Ожидание по условию, а не sleep. Локаторы по стабильным атрибутам вроде data-testid, а не по цепочке классов вёрстки.
Про набор целиком скажите отдельно: время прогона, запуск в CI на каждый пулл-реквест, разбор красных прогонов как обязанность, а не как фон.
Где спотыкаются
Делают самоцелью процент покрытия и называют норматив. Число ничего не говорит о качестве проверок: можно прогнать код и не проверить ни одного результата.
Тащат всё в интерфейс, потому что так «ближе к пользователю». Такой набор растёт до часов прогона, ломается от каждой перевёрстки и перестаёт быть источником доверия.
Лечат нестабильные тесты перезапусками. Ретрай прячет настоящую гонку в приложении, и однажды красный тест окажется правдой, но его уже никто не читает.