Rivalry2

HTML Diff

1 added 2 removed

Original 2026-01-01

Modified 2026-02-26

1 Тестирование приложений на Django - неотъемлемая часть профессиональной жизни веб-разработчиков на Python. Сюда входит написание различных тестов:

2 <ul><li>Юнит-тестов для отдельных модулей</li>

3 <li>Интеграционных тестов, проверяющих работоспособность всего приложения</li>

4 </ul>В этом уроке мы научимся создавать интеграционные тесты для наших веб-приложений на Django.

5 Веб-приложения работают по сети, обрабатывая HTTP-запросы. Такое поведение придется повторять прямо в тестах или как-то имитировать. Django позволяет использовать оба подхода. Мы остановимся на подходе с подменой веб-сервера, чтобы ускорить запуск и выполнение тестов. В остальном эти тесты проверяют работу приложения от запроса до ответа, что дает очень высокую степень уверенности в том, что приложение работает.

6 <h2>Первый тест</h2>

7 - Интеграционные тесты в Django связаны с маршрутами. Кажд��й тест - это запрос на конкретный адрес для тестирования конкретного маршрута. Количество тестов для одного маршрута может быть разным, но конкретный тест - это всегда запрос-ответ.

7 + Интеграционные тесты в Django связаны с маршрутами. Каждый тест - это запрос на конкретный адрес для тестирования конкретного маршрута. Количество тестов для одного маршрута может быть разным, но конкретный тест - это всегда запрос-ответ.

8 Начнем с примера. Предположим, что у нас есть маршрут/users/, который возвращает список пользователей. Тест на такой маршрут должен выполнить запрос на этот адрес. Вот как будет выглядеть структура файлов в этом случае:

9 - . ├── manage.py ├── pyproject.toml └── simple_blog ├── users │ ├── admin.py │ ├── apps.py │ ├── __init__.py │ ├── migrations │ │ ├── 0001_initial.py │ │ └── __init__.py │ ├── models.py │ ├── tests.py │ ├── urls.py │ └── views.py

10 Тесты расположены в директории приложенияsimple_blog/users/.

9 Тесты расположены в директории приложенияsimple_blog/users/.

11 Сам тест выглядит так:

10 Сам тест выглядит так:

12 Файл тестов - это класс фреймворка unittest, в котором тестовые методы начинаются с test_. Во время теста Django делает запрос через специальный объект client. Разберем по шагам:

11 Файл тестов - это класс фреймворка unittest, в котором тестовые методы начинаются с test_. Во время теста Django делает запрос через специальный объект client. Разберем по шагам:

13 <ul><li>Метод get(reverse("users:index")) формирует объект запроса к указанной странице. Кроме GET запроса, мы можем выполнить любой другой запрос. На самом деле здесь не происходит HTTP-вызова - запрос передается в приложение напрямую, поэтому тесты работают быстрее, чем с реальным веб-сервером</li>

12 <ul><li>Метод get(reverse("users:index")) формирует объект запроса к указанной странице. Кроме GET запроса, мы можем выполнить любой другой запрос. На самом деле здесь не происходит HTTP-вызова - запрос передается в приложение напрямую, поэтому тесты работают быстрее, чем с реальным веб-сервером</li>

14 <li>Метод assertEqual(response.status_code, 200) проверяет, что вернулся ответ 200. По необходимости можно проверить любой другой статус</li>

13 <li>Метод assertEqual(response.status_code, 200) проверяет, что вернулся ответ 200. По необходимости можно проверить любой другой статус</li>

15 </ul>Проверка на код ответа считается одной из базовых проверок. Она показывает, что приложение в целом отработало ожидаемо. При этом мы не можем с уверенностью сказать, что все правильно.

14 </ul>Проверка на код ответа считается одной из базовых проверок. Она показывает, что приложение в целом отработало ожидаемо. При этом мы не можем с уверенностью сказать, что все правильно.

16 Например, мы ожидаем, что в теле ответа будет HTML определенной структуры с нужными данными, но вдруг там ничего нет? Для контроля ответа нужно добавить проверку тела ответа.

15 Например, мы ожидаем, что в теле ответа будет HTML определенной структуры с нужными данными, но вдруг там ничего нет? Для контроля ответа нужно добавить проверку тела ответа.

17 И последний шаг - запуск тестов:

16 И последний шаг - запуск тестов:

18 <h2>Взаимодействие с базой</h2>

17 <h2>Взаимодействие с базой</h2>

19 Пример теста списка пользователей не включает в себя одну важную деталь - наполнение базы данных. По умолчанию тесты используют ту базу данных, которая указана в конфигурации. За ее наполнение отвечает программист. Кроме наполнения базы, нам нужна еще и ее очистка.

18 Пример теста списка пользователей не включает в себя одну важную деталь - наполнение базы данных. По умолчанию тесты используют ту базу данных, которая указана в конфигурации. За ее наполнение отвечает программист. Кроме наполнения базы, нам нужна еще и ее очистка.

20 Представьте, что мы написали тест, который создает пользователя. Если после теста мы не удалим этого пользователя, то следующий тест может завершиться с ошибкой - он не рассчитывает, что в базе уже есть такие данные. По этой причине в Django каждый тест выполняется в отдельной транзакции, которая откатывается в конце теста. Таким образом достигается полная изоляция тестов друг от друга.

19 Представьте, что мы написали тест, который создает пользователя. Если после теста мы не удалим этого пользователя, то следующий тест может завершиться с ошибкой - он не рассчитывает, что в базе уже есть такие данные. По этой причине в Django каждый тест выполняется в отдельной транзакции, которая откатывается в конце теста. Таким образом достигается полная изоляция тестов друг от друга.

21 Посмотрим на работу такого теста на примере запроса, обновляющего пользователя. Для этой операции используем маршрут /users/<pk>. Для выполнения запроса нам понадобится идентификатор пользователя.

20 Посмотрим на работу такого теста на примере запроса, обновляющего пользователя. Для этой операции используем маршрут /users/<pk>. Для выполнения запроса нам понадобится идентификатор пользователя.

22 Шаг 1.Сначала мы создаем пользователя. Для наполнения базы данными используется метод setUp().

21 Шаг 1.Сначала мы создаем пользователя. Для наполнения базы данными используется метод setUp().

23 Шаг 2.Затем мы подготавливаем запрос. В самом запросе формируем правильный адрес, подставляя идентификатор созданного пользователя:

22 Шаг 2.Затем мы подготавливаем запрос. В самом запросе формируем правильный адрес, подставляя идентификатор созданного пользователя:

24 Шаг 3.Выполняем запрос и проверяем, что он действительно изменил пользователя в базе данных:

23 Шаг 3.Выполняем запрос и проверяем, что он действительно изменил пользователя в базе данных:

25 Обычно в простых сценариях взаимодействия все наполнение базы можно уместить в setUp(). Но для ситуаций, когда требуется больше данных, лучше воспользоваться Django-фикстурами. Фикстура здесь это набор данных, чаще всего в формате JSON. Самым простым способом создать фикстуру будет сделать дамп, выгрузку данных, базы. Перед этим, разумеется нужно создать какие-то записи в базе.

24 Обычно в простых сценариях взаимодействия все наполнение базы можно уместить в setUp(). Но для ситуаций, когда требуется больше данных, лучше воспользоваться Django-фикстурами. Фикстура здесь это набор данных, чаще всего в формате JSON. Самым простым способом создать фикстуру будет сделать дамп, выгрузку данных, базы. Перед этим, разумеется нужно создать какие-то записи в базе.

26 В результате Django сгенерирует JSON файл, который мы можем уже редактировать. Ниже пример фикстуры users.json в одном из наших проектов.

25 В результате Django сгенерирует JSON файл, который мы можем уже редактировать. Ниже пример фикстуры users.json в одном из наших проектов.

27 После чего фикстуру нужно сохранить в директории приложенияfixturesи уже можем использовать ее в тестах. Django самостоятельно перед каждым тестом, еще до выполнения setUp(), загрузит данные из фикстуры в тестовую базу.

26 После чего фикстуру нужно сохранить в директории приложенияfixturesи уже можем использовать ее в тестах. Django самостоятельно перед каждым тестом, еще до выполнения setUp(), загрузит данные из фикстуры в тестовую базу.

28 Обратите внимание на важную деталь, связанную с интеграционными тестами. На протяжении урока мы писали тесты и убеждались, что приложение работает, даже не посмотрев на реализацию самого приложения. В этом и заключается суть интеграционных тестов. Нам не важно, как написано приложение внутри - мы убеждаемся только в том, что оно работает правильно. Из-за этого интеграционные тесты очень устойчивы к изменениям в коде, они меняются в основном из-за изменений API.

27 Обратите внимание на важную деталь, связанную с интеграционными тестами. На протяжении урока мы писали тесты и убеждались, что приложение работает, даже не посмотрев на реализацию самого приложения. В этом и заключается суть интеграционных тестов. Нам не важно, как написано приложение внутри - мы убеждаемся только в том, что оно работает правильно. Из-за этого интеграционные тесты очень устойчивы к изменениям в коде, они меняются в основном из-за изменений API.

29 <h2>Выводы</h2>

28 <h2>Выводы</h2>

30 Мы научились использовать встроенный механизм тестирования для написания тестов на Django. Django-тесты обладают важными преимуществами как бесшовная работа с базой данных, и абстракция браузера. С помощью их сочетания мы можем писать легко тесты проверяющие функционал больших частей приложения.

29 Мы научились использовать встроенный механизм тестирования для написания тестов на Django. Django-тесты обладают важными преимуществами как бесшовная работа с базой данных, и абстракция браузера. С помощью их сочетания мы можем писать легко тесты проверяющие функционал больших частей приложения.