Месяц как работаю QA-автоматизатором в команде из четырёх бэкендеров, Rails 8.1 и Hotwire. Юнит-тестов много, около 2000 на Minitest, а системных ноль, и регресс перед релизом я прохожу руками за два дня. Сама привыкла к RSpec, но тут всё на Minitest. Хочу постепенно автоматизировать и боюсь наделать сто хрупких тестов, которые все возненавидят. С каких сценариев вы бы начали?
Я бы начала не с количества, а с пяти сценариев, за которые больнее всего, если сломаются. Обычно это вход, регистрация, оформление или оплата, главный поиск и что-то из личного кабинета. Порядок, который у меня работал:
- договориться, что системные тесты гоняются в CI отдельным джобом и их падение видно сразу, а не через неделю;
- писать через assert_text и assert_selector, без sleep и без проверок базы после клика;
- данные готовить фикстурами, которые уже есть, а не накликивать через интерфейс;
- каждый автоматизированный сценарий вычёркивать из ручного регресса, чтобы было видно, сколько часов экономится.
Раз проект на Minitest, пишите на Minitest, тащить RSpec ради системных тестов команда не оценит. driven_by там такой же, и Cuprite подключается тем же способом.
С Hotwire есть нюанс: после отправки формы страница часто не перезагружается, Turbo просто меняет кусок. assert_text это переживает, он ждёт. А вот если сравнивать page.current_path руками через assert_equal, проверка не ждёт и может увидеть старый адрес. Для адреса есть assert_current_path, он тоже умеет ждать.
С позиции тимлида: системный тест, который раз в неделю падает без причины, команда начинает игнорировать уже через месяц. Лучше 15 стабильных, чем 80, из которых три всегда красные. И попросите разработчиков ставить data-test на важные кнопки и поля. В Capybara есть Capybara.test_id, после него click_on находит элемент по этому атрибуту, и тесты не ломаются, когда меняют текст.
+1 к data-атрибутам, иначе каждая правка текста на кнопке ломает пару тестов