Как НЕ нужно писать автотесты на Python

Разбираем самые странные антипаттерны в автотестах на Python: от sleep(0.1) и стрелочек вниз до глобальных курсоров и "фреймворков" на 3500 строк. Почему так делать не стоит и какие есть взрослые альтернативы.

В этой статье я разберу несколько типичных ошибок, которые встречаются при написании автотестов на Python. Цель не в том, чтобы высмеять конкретных людей или проекты. Главное — показать абсурдность некоторых подходов, объяснить, как не стоит строить тестовую инфраструктуру и почему это приводит к проблемам.

Задача простая: сэкономить вам время и силы. Чтобы не пришлось потом «переучиваться», избавляться от костылей и проходить болезненный детокс от самодельных «велосипедов». Гораздо продуктивнее с самого начала писать тесты так, чтобы код был качественным, понятным и поддерживаемым.

Дисклеймер. Примеры в статье обобщены и синтетически изменены; цель — разбирать решения, а не авторов. Любые совпадения с реальными проектами случайны. Все рекомендации — про архитектуру и практики, а не про людей.

Эта статья появилась не случайно. Недавно ко мне пришёл студент с курса и задал вопрос: «Я нашёл фреймворк для автотестов. Это вообще нормальная практика? Так делают?»

Когда я открыл ссылку и посмотрел код, увидел монолитный файл с перемешанными зонами ответственности. Передо мной оказалась «библиотека», которая позиционировала себя как универсальный фреймворк для автотестов «на все случаи жизни». Внутри — один-единственный файл на 3500 строк, в который было запихнуто всё подряд: UI-тесты, API-тесты, обёртки, тулзы, хелперы, нагрузочные тесты и даже системные утилиты. Получился не фреймворк, а монолит без архитектуры.

И самое удивительное: со слов студента, этот «фреймворк» преподносится как «лёгкий способ писать автотесты». В этой статье мы разберём, почему это совсем не лёгкий путь, а скорее быстрый путь к нестабильным тестам и техническому долгу.

Скажу сразу: я не буду давать ссылок и называть авторов. Цель статьи не в том, чтобы кого-то высмеивать или унизить. Цель — разобрать архитектурные ошибки, подсветить костыли, велосипеды и антипаттерны. Подобный код, увы, встречается не только здесь: он реально используется на проектах, да ещё и подаётся новичкам как «правильный подход».

Поэтому давайте вместе проведём небольшой «детокс» от подобных решений.

Симптом. В коде десятки функций вида «нажми стрелку вниз N раз, вдруг элемент окажется в видимой области». Часто ещё с time.sleep(0.1) в цикле и попыткой кликнуть «когда повезёт».

import time from selenium.webdriver import ActionChains from selenium.webdriver.common.keys import Keys from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def make_displayed_with_arrow_down_and_click(driver, xpath, waiting_time): end = time.time() + waiting_time while time.time() < end: try: el = WebDriverWait(driver, 0.2).until( EC.visibility_of_element_located((By.XPATH, xpath)) ) if el.is_displayed(): el.click() return True except: pass ActionChains(driver).send_keys(Keys.ARROW_DOWN).perform() time.sleep(0.1) return False

Flaky и гонки. time.sleep() маскирует проблему синхронизации, а не решает её. На CI такие тесты «мигают».
Зависимость от фокуса. Клавиши работают только если нужный контейнер в фокусе. Любой поп-ап/модал — и всё сломалось.
Дублирование/раздувание. Вариации «стрелка вниз/вверх/ENTER/SPACE» плодят десятки однотипных функций.
Обход DOM-модели. Вместо явного скролла к элементу — «надеемся», что страница сама промотается.
Смешение ожиданий. Параллельно могут быть неявные ожидания — итогом становятся непредсказуемые тайм-ауты.

Почему: автоожидания «из коробки», стабильные локаторы, нормальный скролл, перехват сети/консоли, меньше кода — меньше flaky.

# pip install playwright pytest-playwright # playwright install from playwright.sync_api import Page def click(page: Page, locator: str): # Playwright сам дождётся видимости/кликабельности и доскроллит page.locator(locator).click() def type_text(page: Page, locator: str, text: str): page.locator(locator).fill(text) def get_text(page: Page, locator: str) -> str: return page.locator(locator).inner_text() def click_in_scroll_container(page: Page, container: str): container_locator = page.locator(container) container_locator.scroll_into_view_if_needed() container_locator.click()

Никаких «стрелок вниз», sleep(0.1) и шаманства с ActionChains.
Локаторы лучше писать не XPath-«простынями», а через data-test-id:page.get_by_test_id(locator).click().

Если проект уже на Selenium и переписать нельзя, сводим утилиты к минимуму и не используем клавиши как костыли:

from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.common.exceptions import ElementClickInterceptedException def click(driver, xpath: str, timeout: int = 10) -> None: locator = (By.XPATH, xpath) el = WebDriverWait(driver, timeout).until(EC.element_to_be_clickable(locator)) driver.execute_script("arguments[0].scrollIntoView({block:'center', inline:'center'})", el) try: el.click() except ElementClickInterceptedException: driver.execute_script("arguments[0].click()", el) # редкий резерв def type_text(driver, xpath: str, text: str, timeout: int = 10) -> None: el = WebDriverWait(driver, timeout).until(EC.visibility_of_element_located((By.XPATH, xpath))) el.clear() el.send_keys(text)

Только если вы намеренно тестируете доступность/навигацию клавиатурой (Tab flow, меню-стрелки, хоткеи). Для «проскроллить и кликнуть» — это антипаттерн.

Playwright по умолчанию (автоожидания, стабильные локаторы).
Если Selenium — только явные ожидания + scrollIntoView, без sleep.
Один-два универсальных хелпера вместо десятков «стрелка вниз N раз».
JS-клик — как исключение, а не как стратегия.

Симптом. Функция отправки HTTP-запроса выполняет произвольный код перед запросом, смешивает ответственность и не контролирует ошибки.

def post_request(requests_url: str, requests_body: dict, requests_headers: dict, pre_script: str = None, auth: list = None): # запускаем произвольный код «для подготовки» 🤦 if pre_script is not None: exec(pre_script) body = json.dumps(requests_body) response = requests.post(requests_url, auth=auth, data=body, headers=requests_headers) if response.status_code in (200, 201): print('POST request successful') return response.json() else: print('POST request failed') return response.json()

exec(pre_script) — выполнение произвольного кода из строки. Это уязвимость класса RCE. Доверие к данным ≠ повод их исполнять.
Смешение ответственности. В одном методе «бизнес-логика препроцессинга», сериализация, сетевой вызов и «молчаливое» игнорирование ошибок.
data=body вместо json=... — рискуете неверным Content-Type и кодировкой (и ручной сериализацией там, где она не нужна).
Отсутствие таймаутов/ретраев — подвисания и flaky на CI.
Нет возврата контракта. Неясно, что возвращает метод, как обрабатывать 4xx/5xx.

import httpx class HTTPClient: def __init__(self, client: httpx.Client): self.client = client def post(self, url: str, json: dict, headers: dict | None = None) -> httpx.Response: return self.client.post(url, json=json, headers=headers) def close(self): self.client.close() # пример client = HTTPClient(httpx.Client(timeout=5)) resp = client.post("https://api.example.com/login", json={"user": "foo"}) print(resp.status_code, resp.json())

import httpx from backoff import on_exception, expo # pip install backoff class HTTPClient: def __init__(self, client: httpx.AsyncClient): self.client = client @on_exception(expo, (httpx.TimeoutException, httpx.ConnectError), max_tries=3) async def post(self, url: str, json: dict, headers: dict | None = None) -> httpx.Response: return await self.client.post(url, json=json, headers=headers) async def aclose(self): await self.client.aclose()

from pydantic import BaseModel class LoginRequest(BaseModel): username: str password: str class LoginResponse(BaseModel): access_token: str token_type: str = "Bearer" # пример использования payload = LoginRequest(username="foo", password="bar").model_dump() resp = client.post("https://api.example.com/login", json=payload) parsed = LoginResponse.model_validate_json(resp.text)

Никаких exec, eval, «прескриптов» строкой.
Сериализация — через json=; заголовки задаём явно, если нужно.
Всегда таймауты; для нестабильных сетей — ретраи с экспонентой.
Единый и предсказуемый контракт возврата (или исключения).
Валидация входа/выхода (Pydantic) — меньше сюрпризов в тестах.
Логи: метод, URL, статус, latency (без утечек чувствительных данных).
Не используем bare except: ловите конкретные исключения httpx/requests

Симптом. Подключение к БД и курсор создаются один раз «где-то сверху», кладутся в глобальные переменные и дальше используются из любой функции.

# где-то в модуле global connection, cursor connection = psycopg2.connect(host=..., user=..., password=..., dbname=...) cursor = connection.cursor() def export_table(...): cursor.execute(sql) # используем глобальный курсор rows = cursor.fetchall() ... # в finally где-нибудь ниже: cursor.close(); connection.close()

Утечки и «висящие» транзакции. Глобальный коннект легко забыть закрыть; автокоммит / неявные транзакции висят между тестами.
Не потокобезопасно. Параллельный запуск (pytest-xdist) или просто несколько тестов одновременно — и вы ловите гонки/«курсор уже закрыт».
Неизолированные тесты. Один тест меняет состояние БД — другой видит мусор.
Нельзя конфигурировать точечно. Хотите иной таймаут/роль/схему — увы, «у нас один на всех».
Непрозрачные ошибки. Ошибка «где-то» в общем курсоре → падать начинает «всё» и отлаживать больно.

import psycopg2 from typing import Any, Iterable ConnParams = dict[str, Any] def fetch_all(params: ConnParams, sql: str, args: Iterable[Any] | None = None): """Открывает соединение/курсор, выполняет запрос, гарантированно закрывает ресурсы.""" with psycopg2.connect(**params) as conn: with conn.cursor() as cur: cur.execute(sql, args) return cur.fetchall() # автокоммит зависит от настроек; для SELECT это ок def execute(params: ConnParams, sql: str, args: Iterable[Any] | None = None) -> int: """Для INSERT/UPDATE/DELETE — возвращает число затронутых строк, коммитит транзакцию.""" with psycopg2.connect(**params) as conn: with conn.cursor() as cur: cur.execute(sql, args) return cur.rowcount

Каждый вызов сам управляет ресурсами — нет глобального состояния.
Параметризация через args — защита от SQL-инъекций (никаких f"... {user_id} ...").
Конфигурация (host, dbname, options/search_path) — на уровне вызова.

from psycopg2.pool import ThreadedConnectionPool pool = ThreadedConnectionPool(minconn=1, maxconn=10, **conn_params) def run_in_pool(sql: str, args=None): conn = pool.getconn() try: with conn, conn.cursor() as cur: cur.execute(sql, args) return cur.fetchall() if cur.description else cur.rowcount finally: pool.putconn(conn)

Подойдёт для тестовых раннеров, которые часто ходят в БД.
Всё ещё без глобального курсора и с аккуратным возвратом соединения.

from sqlalchemy import create_engine, text engine = create_engine("postgresql+psycopg2://user:pass@host:5432/dbname", future=True) def fetch_sa(sql: str, **params): with engine.connect() as conn: res = conn.execute(text(sql), params) return res.mappings().all() # список dict’ов

Менеджер соединений, параметризация, кросс-СУБД, удобные маппинги.
Для сложных проектов — ORM/модели, миграции Alembic.

Чтобы тесты не пачкали БД и не зависели друг от друга — оборачиваем каждый тест в транзакцию и откатываем её.

import psycopg2, pytest @pytest.fixture(scope="session") def db_conn(params): conn = psycopg2.connect(**params) conn.autocommit = False yield conn conn.close() @pytest.fixture def db_cur(db_conn): cur = db_conn.cursor() db_conn.begin() # новая транзакция try: yield cur # тест выполняет SQL здесь db_conn.rollback() # откатить изменения после каждого теста finally: cur.close()

Каждый тест получает чистое состояние, изменения не «протекают».
Можно дополнить SAVEPOINT/begin_nested для более тонкой грануляции.

Никаких global connection, cursor.
Всегда with connect() as conn, conn.cursor() as cur:.
Параметризованные запросы (cur.execute(sql, args)), не f-строки с данными.
Для массовых вызовов — пул соединений.
Для реальных проектов — SQLAlchemy (Core/ORM) + миграции.
В тестах — транзакция на тест и обязательный rollback.
Разные СУБД — разные модули/клиенты, не «всё в одном классе».
Разделяйте креды/DSN через переменные окружения (не хардкодим в коде).

Симптом. Внутри «фреймворка автотестов» есть функция, которая лезет в ОС и устанавливает системные пакеты — Node.js, npm и Newman — причём разными путями для Windows/macOS/Linux, местами через sudo, местами скачивая MSI.

def install_newman(): def is_tool_installed(tool): subprocess.run([tool, "--version"], check=True) def install_nodejs(): if sys.platform.startswith("win"): subprocess.run(["curl", "-o", "node.msi", NODE_URL], check=True) subprocess.run(["msiexec", "/i", "node.msi", "/quiet", "/norestart"], check=True) elif sys.platform.startswith("darwin"): subprocess.run(["brew", "install", "node"], check=True) elif sys.platform.startswith("linux"): distro = subprocess.run(["lsb_release", "-is"], stdout=PIPE).stdout.decode().strip().lower() if distro in ["ubuntu", "debian"]: subprocess.run(["sudo", "apt", "update"], check=True) subprocess.run(["sudo", "apt", "install", "-y", "nodejs"], check=True) # ... и т.д. if not is_tool_installed("node"): install_nodejs() if not is_tool_installed("npm"): # ещё одна ветка с пакетными менеджерами и sudo ... if not is_tool_installed("newman"): subprocess.run(["npm", "install", "-g", "newman"], check=True)

Нарушение границ ответственности. Тестовая библиотека не должна администрировать ОС. Это задача DevOps/окружения, а не кода в framework_for_tests.py.
Безопасность. sudo, скачивание и установка бинарей «на лету» из тестов — это прямое приглашение к RCE/порче машины.
Неповторяемость. Сегодня apt install nodejs поставил v18, завтра v22. Результаты «тестов» будут разными.
Ломает CI/CD. Контейнеры собраны заранее. Любая попытка ставить системный софт во время теста — медленно, нестабильно и часто попросту запрещено.
Скрытые побочки. Глобальная установка npm -g newman меняет окружение разработчика/агента. Откаты нет.

Dockerfile (фрагмент):

FROM python:3.12-slim # 1) Python-зависимости COPY requirements.txt . RUN pip install -r requirements.txt # 2) Node.js + Newman (фиксированные версии) RUN apt-get update && apt-get install -y curl ca-certificates gnupg \ && mkdir -p /etc/apt/keyrings \ && curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key \ | gpg --dearmor -o /etc/apt/keyrings/nodesource.gpg \ && echo "deb [signed-by=/etc/apt/keyrings/nodesource.gpg] https://deb.nodesource.com/node_18.x nodistro main" \ > /etc/apt/sources.list.d/nodesource.list \ && apt-get update && apt-get install -y nodejs \ && npm install -g newman@5.3.2 \ && apt-get clean && rm -rf /var/lib/apt/lists/* WORKDIR /app COPY . .

Всё ставится на этапе сборки, версии зафиксированы.
В рантайме тесты не лезут в ОС.

Makefile (фрагмент):

deps: \tpip install -r requirements.txt \tnpm install -g newman@5.3.2 test: \tpytest -m "not e2e" perf: \tnewman run perf_collection.json -e perf_env.json

Инсталляция и запуск — отдельные цели.
Тестовая библиотека не знает про установку системных утилит.

import shutil, subprocess def run_newman(collection: str, env: str) -> int: newman = shutil.which("newman") if not newman: raise RuntimeError("newman is not installed. Please install it via Docker image or CI step.") return subprocess.run([newman, "run", collection, "-e", env], check=False).returncode

Явно падаем с понятной ошибкой, если зависимости нет.
Никаких sudo и «магии установки».

Для API — httpx + pytest (и отчётность Allure).
Для нагрузки — Locust/k6 (метрики, сценарии, профили).
Для E2E — Playwright, у которого есть трейсинг/видео, сетевые HAR без плясок.

Никогда не ставим системный софт из тестовой библиотеки.
Все системные зависимости — в Dockerfile или в CI шаге.
Версии фиксируем (lockfile/теги).
В тестовом коде — только проверка наличия инструмента и аккуратный вызов.
По возможности заменяем «внешние CLI» на библиотечные вызовы в Python/Playwright/Locust.

Симптом. Фреймворк называет «нагрузочным тестом» просто пачку параллельных HTTP-запросов через asyncio.gather, помеченных @pytest.mark.asyncio. Где-то печатается текст «Count = N», и на этом «перфоманс» заканчивается.

class Load: @staticmethod @pytest.mark.asyncio async def make_get_request(url): async with httpx.AsyncClient() as client: response = await client.get(url) response.raise_for_status() return url, response.text @staticmethod @pytest.mark.asyncio async def concurrent_get_requests(urls): tasks = [Load.make_get_request(u) for u in urls] return await asyncio.gather(*tasks) @staticmethod async def run_load_method_of_get_requests(url, count): urls = [url] * count results = await Load.concurrent_get_requests(urls) for u, text in results: print(f"Count = {count}, URL: {u}, Response: {text}")

Это не нагрузочное тестирование. Нет профиля нагрузки (RPS/Concurrency/Duration), нет прогрева, нет стабилизации, нет измерений latency/percentiles, нет ошибок/таймаутов в отчёте, нет корреляции с метриками сервера (CPU, память, сеть).
Смешение с pytest. Навешивание @pytest.mark.asyncio на утилиты ломает запуск вне pytest и «привязывает» код к раннеру тестов.
Отсутствие контроля времени. asyncio.gather максимизирует параллелизм «сколько успели», но не удерживает профиль (RPS/конкарренси/длительность), поэтому данные о p95/p99 и SLA нерепрезентативны.
Нереалистичный сценарий. Нет сессий, куков, заголовков, вариативности payload’ов, зависимостей между шагами.
Никакой отчётности. Печать в консоль — это не репорт. Нужны агрегаты: p50/p90/p99, ошибки по кодам, пер-запросная статистика, графики.

Locust (Python, сценарный подход):

# pip install locust from locust import HttpUser, task, between class WebsiteUser(HttpUser): wait_time = between(0.5, 2.0) # «дум-таймы» между шагами @task(3) def view_items(self): self.client.get("/items", name="GET /items") @task(1) def create_item(self): self.client.post("/items", json={"name": "foo"}, name="POST /items")

Запуск с профилем нагрузки:

locust -H https://api.example.com --headless -u 200 -r 20 -t 10m

-u 200: одновременно 200 пользователей,
-r 20: разгон по 20 пользователей/сек,
-t 10m: длительность 10 минут.

Locust отдаёт p50/p90/p95/p99, RPS, ошибки, можно экспортировать CSV и интегрировать с Grafana/Prometheus.

k6 (альтернатива): декларативные сценарии, отличный вывод метрик и удобная интеграция с Grafana/InfluxDB.

Сеансы и данные. Реалистичные пользователи/куки/токены, вариативные payload’ы, подготовленные фикстуры/сидинг.
Наблюдаемость. Корреляция RPS/latency с CPU/Memory/GC/DB/Cache. Без этого вы «стреляете в темноту».
Профиль. Разгон, плато, спад; A/B сценарии; фоновые шумовые нагрузки.
Отчёт. p50/p90/p99, Throughput, ошибки по классам (4xx/5xx/таймауты), пер-эндпойнт агрегации, SLA/SLO.

Не маскировать «пачку запросов» под «нагрузочное тестирование».
Использовать Locust/k6 или хотя бы честный раннер с целевым профилем и метриками.
Не вешать @pytest.mark.asyncio на утилиты — выносить раннер отдельно от тестов.
Собирать метрики и строить отчёты; без этого выводы невалидны.
Закладывать реалистичность: сеансы, данные, «дум-таймы», вариативность.

Симптом. Во «фреймворке» десятки однотипных методов: press_down_arrow_key, press_up_arrow_key, press_left_arrow_key, press_right_arrow_key, press_enter_key, press_tab_key, press_backspace_key, press_delete_key, press_space_key, press_char_key, press_character_by_character… Все делают одно и то же: строят ActionChains, жмут клавишу n раз и ещё подсыпают time.sleep(.1) между нажатиями.

def press_down_arrow_key(driver, n): action = ActionChains(driver) for _ in range(n): action.send_keys(Keys.ARROW_DOWN) time.sleep(.1) action.perform() def press_enter_key(driver, n): action = ActionChains(driver) for _ in range(n): action.send_keys(Keys.RETURN) time.sleep(.1) action.perform() def press_character_by_character(driver, my_string: str): action = ActionChains(driver) for ch in my_string: action.send_keys(ch) time.sleep(.1) action.perform()

Дребезг и flaky. Ручные sleep(.1) — это гадание на таймингах. На CI/других машинах поведение будет разным.
Дублирование. Десятки почти одинаковых функций → тяжело поддерживать/менять.
Не по-пользовательски. В E2E мы проверяем сценарии пользователя. Он кликает по видимым элементам; «стрелочками вниз» скроллит редко.
Преждевременная низкоуровневость. Нажатия клавиш — последняя надежда, когда нет нормальных локаторов/методов.
Нарушение ожиданий. Нет явных ожиданий состояния (элемент появится/станет кликабельным), только «жми и надейся».

from selenium.webdriver import ActionChains def press(driver, key, times=1, post_delay=0.0): ac = ActionChains(driver) for _ in range(times): ac.send_keys(key) ac.perform() if post_delay: time.sleep(post_delay)

Использование:

press(driver, Keys.ENTER) press(driver, Keys.ARROW_DOWN, times=3)

Но пользоваться им только когда без клавиатуры никак (например, нативный выпадающий список).

from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def click_when_ready(driver, locator, timeout=10): el = WebDriverWait(driver, timeout).until( EC.element_to_be_clickable(locator) ) el.click()

Использование:

click_when_ready(driver, (By.CSS_SELECTOR, '[data-test="submit"]'))

def scroll_into_view(driver, element): driver.execute_script("arguments[0].scrollIntoView({block:'center', inline:'center'})", element)

И затем клик/взаимодействие по локатору с ожиданием.

Playwright сам делает auto-wait и умеет работать клавиатурой точечно, без ручных sleep.

# клик по кнопке + автоожидания page.get_by_test_id("submit").click() # скролл к элементу не нужен — локатор сам дождётся и дотянется page.locator("text=Next").click() # если всё же нужна клавиатура page.keyboard.press("ArrowDown") page.keyboard.type("hello") # печать строки

Нативные элементы/меню, которые реально управляются стрелками/Tab у живого пользователя.
Доступность (a11y): проверка навигации по Tab/Shift+Tab.
Ввод в поля с масками, где «вклейка» файлами/JS не катит.

Даже в этих случаях минимизируем ручные паузы — лучше дождаться состояния (фокус, видимость, enabled).

Сначала локаторы + ожидания, потом клавиатура как исключение.
Один универсальный press() вместо десятка копий.
Никаких «магических» sleep(.1) внутри хелпера — ждём состояния.
По возможности — Playwright: меньше кода, больше стабильности.
Не эмулируем «скролл стрелками» для доставки элемента в вьюпорт; скроллим к элементу и кликаем.

Симптом. Вместо нормальной загрузки файла «фреймворк» вручную «включает» скрытый <input type="file"> и пробует присвоить ему путь строкой через JS:

def upload_file_by_script(driver, input_xpath, file_path): file_input = driver.find_element(By.XPATH, input_xpath) driver.execute_script("arguments[0].style.display = 'block';", file_input) driver.execute_script("arguments[0].removeAttribute('disabled');", file_input) driver.execute_script(f"arguments[0].value = '{file_path}';", file_input) return True

Браузерная безопасность. Современные браузеры запрещают устанавливать value у input[type=file] через JS. Это сознательное ограничение безопасности. Такой «трюк» либо не сработает, либо сломается при первом же обновлении.
Ломает приложение. Насильная правка display/disabled меняет DOM и состояние виджетов, из-за чего падают обработчики, валидации, стили. Тест больше не имитирует пользователя.
Flaky/нестабильность. Чуть другой CSS/фреймворк — и магия перестаёт работать.
Отсутствие кросс-браузерности. То, что «завелось» в Chromium, часто не работает в Firefox/Safari.

Selenium «умеет» загрузки — просто передайте абсолютный путь:

from selenium.webdriver.common.by import By from pathlib import Path def upload_file(driver, input_locator: tuple[str, str], path: str): abs_path = str(Path(path).resolve()) elem = driver.find_element(*input_locator) elem.send_keys(abs_path) # <-- вот и всё

Примечание: если инпут disabled или реально недоступен, надо кликнуть кнопку/label, которая открывает системный диалог — но сам файл всё равно передаём через send_keys по элементу input, а не через JS.

Иногда <input type="file"> скрыт, а UI — это кастомная кнопка/лейбл. Делайте так:

from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def upload_via_label_then_set(driver, button_locator, input_locator, path): WebDriverWait(driver, 10).until(EC.element_to_be_clickable(button_locator)).click() # После клика framework часто делает input «живым» upload_file(driver, input_locator, path)

Не трогайте display/disabled напрямую — дайте приложению само перевести input в «интерактив».

На удалённом драйвере нужно включить FileDetector, иначе путь будет «на вашей машине», а не на ноде:

from selenium.webdriver.remote.file_detector import LocalFileDetector driver.file_detector = LocalFileDetector() elem = driver.find_element(By.CSS_SELECTOR, 'input[type="file"]') elem.send_keys(str(Path("files/doc.pdf").resolve()))

Если фронт принимает файл только через «перетаскивание», у вас два варианта:

Обойти UI и бить в API загрузки напрямую (предпочтительно для интеграционных тестов).
Или сымитировать drop-события. В Selenium это громоздко. Честнее здесь использовать Playwright.

Playwright решает загрузки «из коробки» и не требует делать элемент видимым:

# Python page.set_input_files('input[type="file"]', 'files/doc.pdf') # если есть отдельная кнопка/лейбл page.get_by_role("button", name="Upload").click() page.set_input_files('input[type="file"]', 'files/doc.pdf') # множественные файлы page.set_input_files('input[type="file"]', ['a.png', 'b.png'])

Для dropzone-виджетов часто достаточно всё равно указать реальный input по селектору — фреймворки держат его в DOM. Если нет — Playwright поддерживает page.dispatch_event('selector', 'drop', data) или используйте API-загрузку.

Относительные пути. Всегда приводите путь к абсолютному.
Iframe. Если input внутри iframe — сначала frame = page.frame(name="...") / driver.switch_to.frame(...), потом — загрузка.
Множественный input. Для нескольких файлов нужен атрибут multiple у input; иначе грузите по одному.
Антивирус/сети. На CI путь должен существовать на агенте, а не на вашей машине. Подкладывайте файлы в репозиторий/артефакты job’а.
Валидации фронта. После загрузки проверяйте UI-состояние: превью, имя файла, прогресс, успешный статус, а не только факт «отдал send_keys».

Загружаем файлы только через send_keys (Selenium) или set_input_files (Playwright).
Для удалённых раннеров — LocalFileDetector.
Кликаем по официальным контролам (кнопка/label), не ломая DOM.
При dropzone — либо API, либо Playwright/сложный сценарий drop-события.
Не назначаем value у file-input через JS.
Не меняем стили/disabled у input для «обхода» — это делает тест невалидным и нестабильным.

Симптом. В «обёртке» над requests/httpx ловятся любые сетевые исключения, после чего руками создаётся «синтетический» Response() с придуманным status_code — например 0 (нет сети), 310 (слишком много редиректов), 520 («неизвестная ошибка»). Снаружи всё выглядит как «нормальный» HTTP-ответ.

import requests def send_get_full_request(url, **kwargs) -> requests.Response: try: return requests.get(url, **kwargs) # реальный ответ (200/4xx/5xx) except requests.exceptions.RequestException as e: # "Синтетический" ответ вместо исключения resp = requests.Response() resp.url = url resp._content = str(e).encode("utf-8") resp.reason = type(e).__name__ if isinstance(e, requests.exceptions.Timeout): resp.status_code = 408 elif isinstance(e, requests.exceptions.ConnectionError): resp.status_code = 0 # 👎 несуществующий код elif isinstance(e, requests.exceptions.TooManyRedirects): resp.status_code = 310 # 👎 нестандартный код else: resp.status_code = 520 # 👎 «левый» код return resp

Подмена семантики. 0 — не HTTP-код вообще; 310/520 — нестандартные. Мониторинг, ретраи, SLA/алёрты, либы-клиенты и middleware перестают корректно отличать сетевые исключения от реальных HTTP-ответов сервера.
Ложная телеметрия. Метрики «ошибок сервера 5xx» вдруг растут из-за таймаутов на клиенте — вы лечите не ту сторону.
Ломается контроль ошибок. Код, который рассчитывает на raise_for_status()/обработку исключений, получает «успешный вызов с кодом 0/520» и идёт дальше.
Диагностика в никуда. Потерян стек исключения, не видно, где именно упали DNS/SSL/коннект/таймаут.
Несовместимость. Ретраи по «кодам 0/520» не работают с стандартными политиками (они ждут исключений, а не выдуманных статусов).

На HTTP-уровне возвращаем реальный ответ (200/3xx/4xx/5xx) и при необходимости вызываем raise_for_status().
На сетевом уровне (таймаут/коннект/DNS/SSL) — не прячем проблему: пробрасываем исключение наружу. Ретраим по типам исключений.

import httpx from backoff import on_exception, expo # pip install backoff class Api: def __init__(self, *, timeout: float = 5.0): self.client = httpx.Client(timeout=timeout) @on_exception(expo, (httpx.ConnectError, httpx.ReadTimeout), max_tries=3) def get(self, url: str, **kwargs) -> httpx.Response: resp = self.client.get(url, **kwargs) return resp # real HTTP response; caller decides to raise_for_status() def close(self): self.client.close() # использование api = Api(timeout=5) try: r = api.get("https://api.example.com/items") r.raise_for_status() # HTTP-ошибки — как HTTP-ошибки data = r.json() except (httpx.ConnectError, httpx.ReadTimeout) as e: # Сетевые исключения: можно ретраить/логировать отдельно ... except httpx.HTTPStatusError as e: # Сервер ответил 4xx/5xx — это уже бизнес-логика обработки ...

from dataclasses import dataclass from typing import Any, Optional import httpx @dataclass class ApiResult: ok: bool status: Optional[int] # None для сетевых ошибок data: Optional[Any] error: Optional[Exception] def safe_get(client: httpx.Client, url: str) -> ApiResult: try: resp = client.get(url) # не скрываем 4xx/5xx: это всё ещё реальный HTTP-ответ return ApiResult(ok=resp.is_success, status=resp.status_code, data=resp.json() if resp.headers.get("content-type","").startswith("application/json") else resp.text, error=None) except httpx.RequestError as e: # сетевой уровень → status=None, ошибка явная return ApiResult(ok=False, status=None, data=None, error=e)

Так тестам и прод-коду понятно, что именно случилось: HTTP-ошибка или сеть.

Таймауты по умолчанию. Никогда не делайте «вечных» запросов.
Ретраи по исключениям, а не по «кодам 0/520». Добавляйте jitter/backoff.
Логируйте отдельными полями: метод, URL, status_code (если есть), тип исключения (если есть), длительность, попытку.
Не глотайте стек. В логах должен сохраняться traceback сетевой ошибки.
Контент-тайп/парсинг. Не зовите бездумно .json(); проверяйте заголовок или используйте .is_success и fallback к text.
Метрики. Разводите «HTTP-ошибки» (4xx/5xx) и «сетевые исключения» (timeout/connect). Это разные SLO и разные владельцы.

Не подменяем исключения на «ответы» с фальш-кодами.
Возвращаем реальный Response; сетевые проблемы — как исключения.
Ретраим по ConnectError/Timeout (backoff + jitter).
Отдельные метрики/логи для HTTP-ошибок и сетевых исключений.
json= вместо ручного json.dumps; raise_for_status() там, где нужно.
Если хочется «универсальный результат» — делаем явную модель, а не придумываем HTTP-коды.

Симптом. Вся логика — от UI и API до SQL, VPN и нагрузочного тестирования — собрана в один гигантский файл на 3500 строк. Никаких модулей, никакой архитектуры, просто «куча всего».

Золотая табличка на таком коде могла бы быть такой:

«Работает — не трогай. Сломалось — не починишь».

# В одном и том же файле lib.py: class LibUI: def click_element_by_xpath(...): ... def press_down_arrow(...): ... # десятки методов для клавиатуры class LibSQL: def connect_postgres(...): ... def connect_mysql(...): ... def execute_query(...): ... class LibAPI: def send_post_request(...): ... def send_get_request(...): ... # внутри ещё exec и «фальшивые коды» # ещё ниже: утилиты для VPN, файловой системы, нагрузочные тесты через httpx, CSV-обработчики...

Нарушение SRP (Single Responsibility Principle). Один файл делает всё сразу. UI ≠ API ≠ SQL ≠ DevOps. Поддерживать невозможно.
Отсутствие модульности. Нельзя переиспользовать кусок кода в другом проекте: он тянет за собой весь «зоопарк».
Гигантский технический долг. Любая правка/рефакторинг → риск поломать чужую часть, потому что тесты завязаны на весь комбайн.
Порог входа. Новичок открывает файл и теряется. Где UI? Где база? Где API? Всё в одной простыне.
Нет тестируемости. Такой монолит нельзя изолированно покрыть юнит-тестами. Всё связано через глобалы.

ui.py — обёртки над Playwright/Selenium.
api.py — клиент на httpx.
db.py — SQLAlchemy/psycopg2 утилиты.
load.py — нагрузочные сценарии в Locust.
tools/ — вспомогательные функции (логирование, парсинг).

Каждый модуль отвечает только за своё.

my_framework/ __init__.py ui.py api.py db.py load.py utils/ logging.py files.py

# ui.py from playwright.sync_api import Page def click(page: Page, selector: str): page.locator(selector).click() # api.py import httpx def get(client: httpx.Client, url: str): return client.get(url)

Тестам больше не нужно импортировать «всё подряд». Они используют только нужное.

Никогда не складывать всё в один «бог-файл».
Делить код на модули: UI, API, DB, нагрузка.
Использовать стандартные библиотеки (Playwright, httpx, SQLAlchemy, Locust).
Следовать SRP: один модуль = одна зона ответственности.
Писать юнит-тесты на утилиты, а не на «комбайн».

На первый взгляд подобные «фреймворки» кажутся простыми и удобными: вызвал статический метод LibUI.click_element_by_xpath(...) — и тест готов. Но это иллюзия простоты, за которую потом приходится очень дорого платить.

Проблема в том, что авторы подобных решений сами не осознают глубину своих ошибок. Отсюда рождаются неудачные практики и самодельные обёртки/комбайны, хотя индустрия уже давно выработала зрелые инструменты и практики: Playwright для UI, httpx для HTTP, pytest для тестов, locust для нагрузки. Эти библиотеки не нуждаются в обёртках на 3500 строк с костылями и хаками.

Формируется ложное представление, что «автоматизация» — это набор случайных статических методов.
Selenium-антипаттерны (sleep, стрелки вниз, дубли функций) закрепляются как «правильная практика».
SQL, API и UI смешаны в одном файле → стираются границы ответственности. Студент перестаёт понимать, где UI, где база, а где сервис.
В реальном проекте такой подход ломается на первом же код-ревью или собеседовании.
Новичку действительно проще «вызвать метод и забыть», но это не обучение, а прививка неподдерживаемого кода. Потом придётся проходить «детокс»: переучиваться и заново строить мышление.

Это не библиотека, а несвязанный набор утилит без архитектуры, с дублированием кода и небезопасными конструкциями.
Слоган «пишите меньше кода» достигается не грамотным дизайном, а тем, что всё завязано на костыли и хаки.
Технический долг зашивается прямо в головы новичков: они искренне думают, что «так и надо писать тесты».
Попытка «собрать всё и сразу» приводит к абсурду: UI-обвязка на Selenium, SQL для PostgreSQL/MySQL/SQLite, VPN, API на requests, нагрузка через httpx — всё в одном файле.

На деле мы рассмотрели лишь малую часть. Вся библиотека — это 3500 строк кода, которые проще выбросить и написать с нуля, чем пытаться поддерживать.

Использовать такие вещи в продакшене или даже на учебном проекте — рискованно. Максимум — рассматривать как «справочник» того, что вообще можно сделать с Selenium или requests, а дальше переписать под задачу точечно.

Мы все когда-то писали кривой код. Главное — вовремя от этого отвыкнуть и начать писать правильно. Если у вас есть примеры похожих граблей — поделитесь в комментариях: разберём и добавим в чеклист

Антипаттерны, которые мы рассмотрели, — это не просто «забавные костыли». Это системные ошибки, которые мешают автоматизации развиваться, превращают тесты в источник боли и откладывают технический долг на годы вперёд.

Главная мысль проста: писать автотесты правильно не сложнее, чем писать их неправильно. Разница лишь в том, что «правильные» практики дают надёжный, предсказуемый и поддерживаемый код, а «неправильные» — flaky, хаос и бесконечный рефакторинг.

Если вы только начинаете путь в автоматизации — ориентируйтесь на зрелые инструменты и устоявшиеся подходы:

Playwright или Selenium для UI,
httpx + pytest для API,
SQLAlchemy для работы с БД,
Locust или k6 для нагрузки.

Они уже решают 90% задач «из коробки» и избавляют вас от необходимости собирать собственный «велосипед на 3500 строк».

И самое важное: автотесты — это код. К нему применимы те же правила, что и к боевому продукту: модульность, читаемость, тестируемость, безопасность. Чем раньше вы это усвоите, тем меньше будет «детокса» в будущем.

Так что если вам попадётся библиотека-«комбайн» с магией и костылями — не спешите радоваться, что «писать тесты стало проще». Скорее всего, это ловушка. Лучше потратить чуть больше времени на освоение правильных практик и писать тесты, за которые не будет стыдно ни вам, ни вашему проекту.

Если после этой статьи вы поймали себя на мысли, что часть примеров вам знакома — не беда. Мы все через это проходили. Главное — научиться писать автотесты так, чтобы за них не было стыдно ни на code review, ни на собеседовании.

Как НЕ нужно писать автотесты на Python

Введение

История находки

Антипаттерн 1. «Танцы со стрелочками вниз»

Плохой пример (сокращённо)

Что здесь не так?

Как правильно (коротко и надёжно)

Вариант по умолчанию — Playwright

Когда всё-таки Selenium?

Когда уместны клавиши?

Мини-чеклист вместо «танцев»

Антипаттерн 2. «exec в API» и прочая небезопасная магия

Плохой пример (сокращённо)

Что здесь не так?

Как правильно?

Вариант 1. Небольшой «чистый» синхронный клиент на httpx

Вариант 2. Асинхронный клиент + ретраи (коротко)

(Опционально) Валидация данных через Pydantic

Мини-чеклист безопасности и здравого смысла

Антипаттерн 3. Глобальные connection/cursor

Плохой пример (сокращённо)

Что здесь не так?

Как правильно?

Вариант A. Чистая функция + контекстные менеджеры (psycopg2)

Вариант B. Пул соединений (если запросов много)

Вариант C. SQLAlchemy (индустриальный стандарт)

Тестовая изоляция (очень важно)

Pytest-фикстуры на psycopg2

Мини-чеклист

Антипаттерн 4. «Тестовая библиотека сама ставит Node.js/Newman через sudo»

Плохой пример (сокращённо)

Что здесь не так?

Как правильно?

Вариант A. Контейнер с зафиксированными зависимостями (рекомендуется)

Вариант B. Make/CI-оркестрация — не из тестовой либы

Вариант C. Если Newman очень нужен — оборачивайте вызов с проверкой, но не устанавливайте

Альтернатива Newman: чистый Python или профильные инструменты

Мини-чеклист

Антипаттерн 5. «Нагрузка» через httpx и pytest.mark.asyncio

Плохой пример (сокращённо)

Что здесь не так?

Как правильно?

Использовать профильные инструменты (рекомендовано)

Что ещё важно для «настоящей нагрузки»

Мини-чеклист

Антипаттерн 6. «40 барабанов клавиатуры»

Плохой пример (сокращённо)

Что здесь не так?

Как правильно (Selenium)

1) Убрать зоопарк — оставить один универсальный хелпер

2) Предпочитать действия через локаторы и ожидания

3) Для «прокрутки» — скролл к элементу, а не «стрелки»

Как правильно (Playwright — ещё короче и надёжнее)

Когда клавиатура уместна?

Мини-чеклист

Антипаттерн 7. Загрузка файла «через JS под капотом»

Что здесь не так?

Как правильно (Selenium)

1) Классика: send_keys() на input[type=file]

2) Скрытый (aria-виджеты)

3) Selenium Grid / удалённый драйвер

4) Drag&Drop-виджеты (dropzone)

Как правильно (Playwright — проще и стабильнее)

Частые грабли и как их обойти

Мини-чеклист

Антипаттерн 8. Фальшивые HTTP-ответы и статусы 0/310/520

Плохой пример (сокращённо)

Что здесь не так?

Как правильно?

Вариант A. «Чистый» контракт: либо реальный Response, либо исключение

Вариант B. Если нужен «обобщённый» результат — делаем явную модель

Важные практики!

Мини-чеклист

Антипаттерн 9. «Один файл на 3500 строк — это не фреймворк»

Плохой пример (упрощённо)

Что здесь не так?

Как правильно?

Делим на отдельные модули

Собираем архитектуру «фреймворка» как пакет

Пример