· Дублирование: одни и те же локаторы, хелперы или шаги разбросаны по 10 файлам. · Магические числа и строки: time.sleep(5) и “button.submit” без пояснений. · Тесты зависят друг от друга: запуск поодиночке падает, а порядок важен. · Скорость падает: подготовка данных или логин выполняются внутри каждого теста, хотя можно вынести в фикстуры. · Читаемость на нуле: новый член команды тратит дни, чтобы понять логику.

📋 План рефакторинга: с чего начать

1. Инвентаризация: составьте карту проблемных мест. Используйте линтеры (flake8, pylint) и анализаторы дублирования (jscpd работает и для Python). Заведите задачи в бэклоге с тегом «техдолг».

2. Приоритезация: первыми трогаем то, что меняется чаще всего и вызывает больше всего багов. Хороший ориентир – частота падений в CI.

3. Декомпозиция: не пытайтесь переписать всё сразу. Выделяйте маленькие итерации: «вынести все локаторы страницы логина в отдельный Page Object», «убрать хардкод URL в конфиг».

⚙️ Стратегия безопасного рефакторинга · Зелёная зона: перед любыми изменениями убедитесь, что текущие тесты проходят. Если тесты уже сломаны – сначала почините или зафиксируйте известные дефекты.

· Маленькие шаги + частые коммиты: изменили сигнатуру одного хелпера → запустили связанные тесты → закоммитили. Не смешивайте рефакторинг и добавление новой функциональности.

· Опора на сигнатуры: меняя внутренности, сохраняйте публичный API функций и классов. Если приходится ломать – используйте декораторы-заглушки с предупреждениями на переходный период.

· Параллельный прогон (при крупных изменениях): если меняете работу с БД или API-клиент, временно запускайте старую и новую реализацию и сравнивайте результаты.

🐍 Python-инструменты для рефакторинга автотестов

· pytest фикстуры и параметризация: вынос повторяющейся подготовки данных в фикстуры с scope и yield. Параметризация убирает копипасту однотипных тестов.

· Page Object Model (POM): если ещё не внедрили – начните с наиболее часто используемых страниц. Библиотеки playwright и selenium хорошо ложатся на POM, а pydantic поможет типизировать данные.

· Кастомные маркеры и тестовые данные: вынос тестовых данных в JSON/YAML и чтение через pytest_generate_tests или @pytest.mark.parametrize с загрузкой из файлов.

· Статический анализ и автоформатирование: внедрите black и isort как pre-commit хуки. Они избавят от споров о стиле и сразу приведут код к единообразию.

🧪 Пример до/после: выносим логин в фикстуру До (дублирование в каждом тесте): def test_create_order(): driver.get(“https://example.com/login”) driver.find_element(“id”, “username”).send_keys(“user1”) driver.find_element(“id”, “password”).send_keys(“pass”) driver.find_element(“id”, “login-btn”).click() # … создание заказа

После (фикстура + POM): @pytest.fixture def logged_in(page: Page, test_user): login_page = LoginPage(page) login_page.navigate() login_page.login(test_user.email, test_user.password) yield page def test_create_order(logged_in): # логика заказа, страница уже открыта и залогинена

💬 Золотые правила рефакторинга автотестов · Не ломай обратную совместимость без крайней нужды. Если ломаешь – предупреди команду.

· Каждый рефакторинг должен покрываться существующими тестами (это мета-правило 😄). Если покрытия нет – сначала допиши хотя бы дымовые проверки.

· Веди документацию по архитектуре: README с описанием слоёв (API-клиенты, фикстуры, пейджи) и конвенций.

· Выделяй время: в спринтах резервируй 15-20% ёмкости на техдолг, иначе рефакторинг всегда будет «когда-нибудь потом» #qa #python #automation #refactoring #pytest