🧪 Тестирование кода

Короткий ответ Стратегию стоит строить как пирамиду с основанием из быстрых unit-тестов бизнес-логики, средним слоем интеграционных тестов на границах с БД и внешними сервисами, и тонким верхним слоем e2e-тестов критичных пользовательских сценариев — конкретные пропорции и границы между слоями зависят от критичности сервиса, зрелости команды и стоимости инцидентов. Как это работает подробнее Каждый уровень тестовой пирамиды ловит свой класс ошибок: unit-тесты — ошибки в логике при минимальной стоимости и максимальной скорости; интеграционные — несовместимость с реальной БД, сериализацией, внешними контрактами; e2e — поломки в связке всех компонентов и инфраструктуры, но ценой медленного и более хрупкого прогона. Сравнение Компромисс. Больше unit-тестов — быстрая обратная связь и низкая стоимость поддержки, но риск пропустить ошибки интеграции. Больше интеграционных/e2e — выше уверенность в реальном поведении системы, но дороже в поддержке, медленнее CI и больше flaky-тестов. Критерий выбора: критичность сцена

Читать полностьюend-to-end-testing

Короткий ответ Нужно использовать плагин pytest-asyncio (или pytest-anyio) и помечать тестовую функцию как async def с декоратором @pytest.mark.asyncio, чтобы pytest запустил её внутри event loop, а не просто вызвал как обычную функцию. Как это работает подробнее Без специального плагина pytest не умеет ожидать корутины — async def тест без правильной настройки просто вернёт объект корутины, а не выполнит его, из-за чего тест формально «пройдёт», ничего не проверив. pytest-asyncio оборачивает такие тесты в event loop и дожидается их завершения через await. Пример кода Что использовать на практике Практика. Важно следить за режимом работы event loop в фикстурах (например, asyncio_mode = "auto" или явные маркеры), чтобы асинхронные фикстуры и тесты использовали один и тот же loop. Для асинхронных HTTP-клиентов используют httpx.AsyncClient с ASGITransport вместо синхронного TestClient, если нужно протестировать именно асинхронный путь выполнения. Подводные камни Риск. Забывать @pytest.mark.asyncio или не настраи

Читать полностьюasynchronous-programming

Короткий ответ Нужно тестировать поведение системы на реалистичном профиле нагрузки (смесь типов запросов, распределение по времени, постепенный рост) и смотреть на набор метрик — задержку по перцентилям (p50/p95/p99), частоту ошибок, использование ресурсов, поведение под пиковой и длительной нагрузкой, — а не только на пиковый RPS, который сильно зависит от окружения теста и конкретной конфигурации. Как это работает подробнее Нагрузочный тест (например, через locust или k6) эмулирует параллельных пользователей по сценарию, близкому к реальному трафику, и собирает распределение времени ответа, а не только среднее значение — среднее легко маскирует то, что часть запросов (например, p99) отвечает на порядок медленнее из-за блокировок, N+1-запросов или исчерпания пула соединений с БД под нагрузкой. Сравнение Компромисс. Подробное многометриковое нагрузочное тестирование с реалистичным профилем трафика даёт более достоверную картину, но требует значительных усилий на подготовку сценариев и инфраструктуры, а также

Читать полностьюlatency

Короткий ответ Stub возвращает заранее заданные данные без проверки вызовов, mock дополнительно проверяет, как именно его вызывали, а fake — это упрощённая, но рабочая реализация зависимости (например, БД в памяти вместо настоящей). Как это работает подробнее Stub используют, когда важно только получить предсказуемый результат от зависимости, не интересуясь деталями вызова или тем, сколько раз его вызвали. Mock добавляет к этому проверку поведения теста — какие методы вызваны, с какими аргументами, сколько раз именно. Fake — это отдельная, часто самописная реализация с реальной, пусть и упрощённой логикой, например словарь вместо таблицы в БД, который действительно хранит и возвращает данные. Пример кода Что использовать на практике Практика. В Python чаще всего используют unittest.mock, который фактически совмещает возможности stub и mock в одном объекте — можно и задать возвращаемое значение (return_value), и проверить вызовы. Fake полезен, когда нужна более реалистичная имитация поведения, чем просто фикси

Читать полностьюmocking

Короткий ответ Тесты начинают зависеть от порядка, когда делят общее изменяемое состояние — глобальные переменные, данные в тестовой БД без отката, кеш, файлы на диске — и один тест неявно опирается на состояние, оставленное предыдущим; решение — явная изоляция через фикстуры с очисткой/откатом перед или после каждого теста. Как это работает подробнее Если тест A создаёт запись в БД и не удаляет её, а тест B неявно рассчитывает на пустую таблицу (например, проверяет count() == 0), результат теста B зависит от того, выполнялся ли тест A раньше. Запуск тестов в случайном порядке (pytest-randomly) — хороший способ быстро выявить такие скрытые зависимости. Пример кода Что использовать на практике Практика. Надёжная изоляция обычно достигается транзакционным откатом БД между тестами, пересозданием моков в каждой фикстуре function-уровня вместо модульных глобальных моков, и избеганием мутируемых global/module-level переменных в тестируемом коде либо их явным сбросом в фикстуре. Подводные камни Риск. Использовать mo

Читать полностьюpython

Короткий ответ Property-based тестирование полезно для кода с чёткими инвариантами и большим пространством входных данных (парсеры, сериализация/десериализация, математические операции), но не должно полностью заменять example-based тесты, которые лучше документируют конкретные бизнес-сценарии и граничные случаи, понятные человеку. Как это работает подробнее Вместо фиксированных примеров hypothesis генерирует множество случайных входных данных по описанной стратегии и проверяет, что заданное свойство (инвариант) выполняется для всех них — например, что decode(encode(x)) == x для любого x из определённого диапазона. При падении hypothesis автоматически минимизирует (shrinking) контрпример до простейшего воспроизводимого случая. Сравнение Компромисс. Property-based тесты находят неочевидные граничные случаи, которые человек не всегда придумает вручную, но требуют больше времени на формулировку инвариантов и могут давать более медленные и иногда недетерминированные (по времени выполнения) прогоны. Критерий выбор

Читать полностьюhypothesis

Короткий ответ Scope определяет, как часто пересоздаётся фикстура: function — перед каждым тестом, session — один раз за весь прогон; для тестовой БД обычно создают соединение/схему на уровне session, а очистку данных — на уровне function, чтобы не терять изоляцию тестов. Как это работает подробнее pytest кеширует результат фикстуры в рамках её scope и переиспользует его для всех подходящих тестов, пока scope не завершится, вызывая фикстуру заново только при смене области видимости. Более широкий scope (session, module) снижает накладные расходы на дорогие операции (поднятие контейнера с БД, подключение к сети), а узкий scope (function) обеспечивает полную изоляцию между тестами ценой повторной инициализации. Пример кода Что использовать на практике Практика. Частый паттерн: фикстура session-уровня поднимает engine и применяет миграции один раз за весь прогон, а фикстура function-уровня оборачивает каждый тест в транзакцию и откатывает её после теста (через savepoint или rollback), совмещая скорость дорогой п

Читать полностьюdatabases

Короткий ответ Модульные тесты проверяют отдельные компоненты по отдельности, в изоляции от остальной системы. Интеграционные тесты проверяют взаимодействие модулей между собой и корректность работы с внешними зависимостями, такими как база данных или API. Как это работает подробнее Эти виды тестирования отвечают на разные вопросы и выполняются на разных этапах. Изоляция. Unit-тест проверяет, корректно ли работает отдельная функция или класс сама по себе; при падении сразу видно, какой компонент сломался. Автор и скорость. Модульные тесты обычно пишет разработчик во время разработки, выполняются они быстро и считаются «белым ящиком». Интеграция. Интеграционные тесты ищут дефекты во взаимодействии собранных модулей и их стыках с окружением. Порядок и стоимость. Интеграционное тестирование идёт после модульного и до системного, но оно медленнее и дороже и чаще проводится тестировщиками. Что использовать на практике Пирамида тестов. Основу держи на быстрых модульных тестах, а интеграционные добавляй для критичны

Читать полностьюintegration-tests

Короткий ответ Покрытие показывает, какая доля строк или веток кода была выполнена хотя бы одним тестом, но не проверяет, что тест действительно содержит осмысленные проверки (assert) ожидаемого поведения на этих строках. Как это работает подробнее Инструмент вроде pytest-cov инструментирует код во время прогона тестов и фиксирует, какие строки (line coverage) или ветки условий (branch coverage) были выполнены хотя бы один раз, формируя отчёт в процентах по отдельным файлам, модулям и проекту в целом, с подсветкой непокрытых строк. Пример кода Что использовать на практике Практика. Покрытие полезно, чтобы найти явно непротестированный код — функции или ветки обработки ошибок, которые вообще ни разу не вызывались в тестах. Но тест, который просто вызывает функцию без содержательного assert, засчитает строки как покрытые, хотя фактически ничего не проверил о корректности поведения. Подводные камни Риск. Ставить цель «100% покрытия» как самоцель, что приводит к формальным тестам без содержательных проверок, напи

Читать полностьюbranch-coverage