Как мы подружили Selenium с бракованной версткой через JS-инъекцию, когда фронтенд сказал “нет”

Вспомнил свой первый год на позиции Automation QA. Мы с лидом бились головой об стену: Selenium не мог кликнуть по чекбоксу “Согласен с пользовательским соглашением”. Клик улетал в ссылку на текст соглашения, которая визуально лежала поверх чекбокса. Автотест авторизации падал, а фронтенд-разработчик был один на весь проект и наотрез отказывался трогать верстку. Его логика: “Дизайн утвержден, пользователи кликают без проблем, это ваша проблема, что робот не попадает”.

Мы с лидом потратили день на обсуждения и поиск обходных путей. Двигали локаторы, пробовали ActionChains с offset, меняли тайминги - ничего не работало стабильно. Элемент перекрыт, точка клика уходит в дочернюю ссылку, тест флапает через раз.

И тут меня осенило: а что если не просить фронта, а подвинуть DOM самому прямо в рантайме теста. В голове всплыли старые эксперименты с JavaScriptExecutor. Мы написали микро-инъекцию на JS, которая через execute_script смещала контейнер с ссылкой на несколько пикселей вправо перед кликом по чекбоксу. Буквально margin-left с инлайновым стилем, который не ломал отображение для пользователя, но освобождал зону клика для WebDriver.

Пришлось, конечно, идти согласовывать с руководством, потому что решение выглядело как костыль. И технически это был костыль. Но костыль, который намертво зафиксировал критический бизнес-путь авторизации. С тех пор тесты логина бегут безотказно. И главный урок, который я вынес тогда: automation engineer должен уметь договариваться с системой, даже когда команда не может дать идеальные условия. Иногда лучший фикс - это не убедить разработчика переверстать, а аккуратно подвинуть реальность самому.

А у вас были ситуации, когда приходилось “чинить” тестовое окружение прямо из кода теста?

#qaautomation #selenium #javascriptexecutor #dommanipulation #testautomation #frontendtesting #webdriver #automationqa #testing #qaengineer