Введение
Я работаю backend Python-инженером уже несколько лет. За это время я многому научился: писать чистый код, применять алгоритмы в реальных задачах, работать как с реляционными, так и с нереляционными базами данных, и, что особенно важно, писать действительно полезные тесты. Эти навыки не раз помогали мне экономить время и делать реализуемые фичи более надёжными.
За годы работы разработчиком я сталкивался с разными подходами к тестированию. В этой статье я хочу показать, какие практики кажутся мне неэффективными, и объяснить, как довольно просто писать надёжные тесты, которые дают и хорошее покрытие, и устойчивость.
Статья может быть полезна не только Python-разработчикам, но и инженерам-программистам в целом.
Что такое тесты
Обычно тестами называют код, который проверяет другой код. Чаще всего тесты делят на две группы: unit-тесты и integration-тесты.
-
Unit-тесты проверяют изолированные участки исходного кода и валидируют ожидаемое поведение.
-
Integration-тесты проводятся на уровне интеграции, когда несколько частей системы тестируются совместно, иногда включая интеграцию с внешними системами.
По поводу того, как именно относить тесты к этим группам, мнения различаются. Кто-то считает, что unit-тестами можно называть только проверки очень маленьких фрагментов кода, а более сложные сценарии всегда должны считаться integration-тестами. Я придерживаюсь другой позиции: unit-тесты вполне могут проверять сразу несколько частей кода, тогда как integration-тестирование — это уже проверка целых модулей, например сервисов, работающих вместе через интерфейс. Я называю такие проверки unit-тестами с реальными зависимостями.
Кроме того, за всё время работы я почти не видел проектов, где разработчики действительно писали тест на каждый отдельный метод или маленький блок кода. На практике намного удобнее тестировать более крупные участки логики без необходимости писать отдельный тест на каждую функцию — они всё равно покрываются в составе общего сценария.
В рамках этой статьи я буду называть всё это просто тестами, потому что независимо от терминологии важно одно: чтобы тесты у вас были.
Ненадёжные тесты
За время своей карьеры я работал над разными проектами. Иногда я приходил в команды, где продукт уже давно развивался. Мне доводилось видеть разные реализации тестов, и некоторые из них оказывались ненадёжными. В этой части статьи я постараюсь обобщить такие случаи, показать примеры кода и объяснить, в чём именно проблема подобных подходов.
Для примера рассмотрим простое FastAPI-приложение с несколькими методами: получение данных из базы, добавление данных и обновление.
from fastapi import FastAPI, Body, HTTPExceptionfrom core.db import queriesfrom core import schemasapp = FastAPI()@app.get( "/items", summary="Get items", status_code=200, response_model=list[schemas.ItemSchema],)def get_items() -> list[schemas.ItemSchema]: items = queries.get_items() return items@app.post( "/items", summary="Add items", status_code=200, response_model=list[schemas.ItemSchema],)def add_items( items: list[schemas.ItemBaseSchema] = Body( ..., embed=True, )) -> list[schemas.ItemSchema]: added_items = queries.add_items( items=items ) return added_items@app.patch( "/items/{item_id}", summary="Update an item", status_code=200, response_model=schemas.ItemSchema,)def update_item( item_id: int, update_data: schemas.ItemBaseSchema = Body( ..., embed=True, )) -> None: if queries.get_item( item_id=item_id ) is None: raise HTTPException(status_code=404, detail="Item not found") item = queries.update_item( item_id=item_id, update_data=update_data, ) return item@app.delete( "/items/{item_id}", summary="Delete an item", status_code=204,)def delete_item( item_id: int) -> None: if queries.get_item( item_id=item_id ) is None: raise HTTPException(status_code=404, detail="Item not found") queries.delete_item( item_id=item_id )
Как видно, это простое API с CRUD-операциями. Я покажу примеры тестов для такого API, с которыми мне приходилось сталкиваться в работе, и разберу, какие у них есть недостатки.
В этом примере я специально собрал несколько распространённых практик тестирования, которые со временем могут привести к проблемам.
import jsonimport pytestfrom fastapi import statusfrom sqlalchemy import create_enginefrom sqlalchemy.orm import sessionmakerfrom core.db.models import Item@pytest.fixture(scope='session')def db_item(test_db_url, setup_db, setup_db_tables): engine = create_engine( test_db_url, echo=False, echo_pool=False, ) session = sessionmaker(autocommit=False, autoflush=False, bind=engine) with session() as session: item = Item( name='name', number=1, is_valid=True, ) session.add( item ) session.commit() session.refresh(item) return item.as_dict()def test_get_items( fastapi_test_client, db_item,): response = fastapi_test_client.get( '/items', ) assert response.status_code == status.HTTP_200_OKdef test_post_items( fastapi_test_client,): item_to_add = { 'name': 'name', 'number': 1, 'is_valid': False, } response = fastapi_test_client.post( '/items', data=json.dumps( { 'items': [ item_to_add ], }, default=str, ), ) assert response.status_code == status.HTTP_200_OKdef test_update_item( fastapi_test_client, db_item,): update_data = { 'name': 'new_name', 'number': 2, 'is_valid': True, } response = fastapi_test_client.patch( f'/items/{db_item["id"]}', data=json.dumps( { 'update_data': update_data, }, default=str, ), ) assert response.status_code == status.HTTP_200_OKdef test_delete_item( fastapi_test_client, db_item,): response = fastapi_test_client.delete( f'/items/{db_item["id"]}', ) assert response.status_code == status.HTTP_204_NO_CONTENT
На первый взгляд такие тесты выглядят нормально. Они покрывают все API, проверяют ответы и дают высокий общий coverage.
Но действительно ли они хороши? Давайте разберёмся, как именно они выполняются.
Важно заметить, что setup_db, setup_db_tables и db_item имеют session scope. Это означает, что такие fixtures уничтожаются только в конце всей тестовой сессии — после выполнения всех тестов.
Порядок запуска здесь будет примерно таким:
-
Создаётся тестовая база данных, если её ещё нет.
-
Создаются таблицы в тестовой базе, если их ещё нет.
-
В тестовой базе создаётся тестовый объект item.
-
Запускаются API-тесты.
-
Таблицы и база данных удаляются.
В такой схеме есть несколько серьёзных проблем.
Первая проблема — база данных и тестовый объект создаются только один раз на весь прогон тестов. Это может привести к проблемам с консистентностью данных между тестами. В такой конфигурации тесты начинают зависеть друг от друга.
Например, если мы добавим новый тест, который читает данные из базы, и он выполнится после теста на DELETE, он может упасть просто потому, что тестовые данные уже удалены.
Даже если до этого запускается POST, который снова создаёт данные, всегда остаётся риск, что порядок изменится или какой-то тест будет удалён, и всё начнёт ломаться.
Вторая проблема — и объект в fixture db_item, и данные в test_post_items захардкожены.
Такой подход работает ровно до тех пор, пока в базе не появляется конфликт. Сейчас в примере нет никаких дополнительных constraints, кроме Item.id как первичного ключа. Но если в будущем ограничения появятся, тесты легко могут начать падать, потому что они опираются на фиксированные значения и не учитывают возможные конфликты.
И это снова подчёркивает, что тесты оказываются зависимыми друг от друга.
Третья проблема — такие тесты вообще не проверяют, что методы действительно работают корректно. Они лишь проверяют, что response code совпадает с ожидаемым, но не подтверждают, что данные реально были изменены в базе или корректно из неё получены.
В текущем виде, просто запустив эти тесты, нельзя с уверенностью сказать, что методы действительно работают как нужно. По сути, единственный способ убедиться в этом — дополнять автоматические тесты ручной проверкой.
Все эти недостатки можно свести к трём основным пунктам:
-
Зависимость: тесты слишком сильно зависят друг от друга, поэтому изменение порядка выполнения может вызывать падения.
-
Ненадёжность: хардкод значений и отсутствие полноценной проверки делают тесты уязвимыми и неточными.
-
Требуют постоянного внимания: без дополнительного ручного QA нет уверенности, что методы действительно работают корректно.
Как улучшить тесты
Ранее мы увидели, что просто наличие тестов ещё не гарантирует надёжность системы.
Хорошая новость в том, что Python, как и другие языки программирования, даёт инструменты, которые помогают сделать тесты устойчивее. А то, что нельзя закрыть инструментами, обычно решается довольно простыми best practices.
Первый ключевой принцип надёжных тестов — независимость. По возможности тесты не должны влиять друг на друга. У каждого теста должны быть собственные данные, свои переменные и собственное окружение. Изменения в одном тесте не должны ломать или менять выполнение остальных.
Поэтому при использовании любого datasource в приложении очень важно очищать данные перед каждым тестом, чтобы не оставалось артефактов, которые повлияют на следующий запуск.
В нашем примере этого можно добиться, если изменить scope fixture setup_db_tables с session на function. Тогда fixture будет выглядеть так:
@pytest.fixture(scope="function")def setup_db_tables(setup_db, test_db_url): create_db_engine = create_engine(test_db_url) BaseModel.metadata.create_all(bind=create_db_engine) yield BaseModel.metadata.drop_all(bind=create_db_engine)
Второй шаг — создавать тестовые данные внутри самих тестов, когда это необходимо.
Для генерации уникальных данных на лету удобно использовать пакет Factory boy.
Он также позволяет создавать объекты сразу в базе данных. Если немного модифицировать его стандартный класс Factory, можно сделать собственную фабрику, которая будет автоматически добавлять объекты в базу:
import factoryfrom tests import conftestclass CustomSQLAlchemyModelFactory(factory.Factory): class Meta: abstract = True @classmethod def _create(cls, model_class, *args, **kwargs): with conftest.db_test_session() as session: session.expire_on_commit = False obj = model_class(*args, **kwargs) session.add(obj) session.commit() session.expunge_all() return obj
После этого достаточно наследоваться от этой кастомной фабрики, чтобы создавать объекты модели прямо в базе.
class ItemModelFactory(CustomSQLAlchemyModelFactory): class Meta: model = models.Item name = factory.Faker("word") number = factory.Faker("pyint") is_valid = factory.Faker("boolean")
И наконец, простой проверки, что метод не вернул ошибку, недостаточно. Нужно проверять результат работы тестируемого метода и любые внутренние изменения, которые он вызывает — например, изменение данных в базе.
Кроме того, очень важно заранее чётко определить, чего именно мы ожидаем от каждого теста.
Тесты после изменений
После небольших изменений в соответствии с описанными выше принципами добиться надёжности становится намного проще. Тесты будут выглядеть уже так:
import jsonfrom unittest.mock import ANYimport pytestfrom fastapi import statusfrom sqlalchemy import create_enginefrom sqlalchemy.orm import sessionmakerfrom core.db.models import Itemfrom tests import factoriesdef test_get_items( fastapi_test_client): expected_items = factories.models_factory.ItemModelFactory.create_batch( size=5 ) response = fastapi_test_client.get( '/items', ) assert response.status_code == status.HTTP_200_OK response_data = response.json() assert response_data == [ { 'id': item.id, 'name': item.name, 'number': item.number, 'is_valid': item.is_valid, } for item in expected_items ]def test_post_items( fastapi_test_client, test_db_session,): assert test_db_session.query(Item).first() is None item_to_add = factories.schemas_factory.ItemBaseSchemaFactory.create() response = fastapi_test_client.post( '/items', data=json.dumps( { 'items': [ item_to_add.dict() ], }, default=str, ), ) assert response.status_code == status.HTTP_200_OK response_data = response.json() assert response_data == [ { 'id': ANY, 'name': item_to_add.name, 'number': item_to_add.number, 'is_valid': item_to_add.is_valid, }, ] assert test_db_session.query(Item).filter( Item.name == item_to_add.name, Item.number == item_to_add.number, Item.is_valid == item_to_add.is_valid ).first()def test_update_item( fastapi_test_client, test_db_session,): item = factories.models_factory.ItemModelFactory.create() update_data = factories.schemas_factory.ItemBaseSchemaFactory.create() response = fastapi_test_client.patch( f'/items/{item.id}', data=json.dumps( { 'update_data': update_data.dict(), }, default=str, ), ) assert response.status_code == status.HTTP_200_OK response_data = response.json() assert response_data == { 'id': ANY, 'name': update_data.name, 'number': update_data.number, 'is_valid': update_data.is_valid, } assert test_db_session.query(Item).filter( Item.name == update_data.name, Item.number == update_data.number, Item.is_valid == update_data.is_valid ).first()def test_delete_item( fastapi_test_client, test_db_session,): item = factories.models_factory.ItemModelFactory.create() response = fastapi_test_client.delete( f'/items/{item.id}', ) assert response.status_code == status.HTTP_204_NO_CONTENT assert test_db_session.query(Item).first() is None
Заключение
В этой статье мы разобрали распространённые проблемы в практиках тестирования, с которыми можно столкнуться в разработке, и рассмотрели их на примере FastAPI-приложения.
Мы увидели несколько типичных недостатков: зависимость тестов друг от друга, использование захардкоженных значений и отсутствие реальной проверки того, что тестируемые методы действительно работают правильно.
Чтобы исправить это, мы обсудили базовые, но очень важные практики: использование fixtures с function scope для изоляции данных, генерацию уникальных тестовых данных с помощью Factory Boy, а также проверку не только результата ответа, но и внутренних изменений, которые происходят в системе. Следуя этим принципам, можно заметно повысить надёжность тестов и лучше гарантировать корректное поведение приложения.
Вот основные правила, которые помогают писать хорошие тесты:
-
Изоляция: данные должны быть изолированы для каждого теста.
-
Динамическая генерация тестовых данных: используйте инструменты вроде Factory Boy, чтобы создавать уникальные данные на лету и не полагаться на хардкод.
-
Чётко определённые ожидания: заранее формулируйте, что именно должен проверить каждый тест.
-
Не смешивайте тест-кейсы: каждый тест должен проверять конкретный сценарий.
-
Проверяйте реальную функциональность: тесты должны не только убеждаться, что не было ошибок, но и валидировать корректность результата и внутренних изменений, например в базе данных.
Надеюсь, статья была полезной. Вы можете клонировать репозиторий с примером из статьи (github).
ссылка на оригинал статьи https://habr.com/ru/articles/1035978/