Написание unit-тестов в Django и DRF
SimpleTestCase и APISimpleTestCase
SimpleTestCase
- подкласс unittest.TestCase
, с расширенной функциональностью. Есть Client
. Нет работы с БД.
APISimpleTestCase
- подкласс SimpleTestCase
для тестирования DRF. Дополнительно использует APIClient
.
TestCase и APITestCase
TestCase
- наиболее часто используемый класс для написания тестов в Django. Он наследуется от TransactionTestCase
(и, соответственно, от SimpleTestCase
).
- Обертывает тесты в два вложенных блока
atomic()
: один для всего класса и один для каждого теста. - Проверяет отложенные ограничения базы данных в конце каждого теста.
- Имеет дополнительный метод
setUpTestData()
APITestCase
- подкласс TestCase
для тестирования DRF. Дополнительно использует APIClient
.
setUpTestData()
Описанный выше блок atomic
на уровне класса позволяет создавать начальные данные на уровне всего класса, один раз для всего TestCase
. Эта техника позволяет ускорить тестирование по сравнению с использованием setUp()
.
|
|
Изменения обектов из
setUpTestData()
в тестовых методах будут сохраняться между всеми тестовыми методами. Изменения можно откатить в методеsetUp()
, например, с помощьюrefresh_from_db()
.
Загрузка данных из fixtures
После того, как мы создали файл с данными (например, в формате .json
) и поместили его в каталог app/fixtures/
нашего приложения, можно использовать его в модульных тестах, указав атрибут класса fixtures
в любом подклассе django.test.TestCase
, например:
|
|
Для улучшения производительности fixtures
загружаются один раз для всего тестового класса. Это происходит перед вызовом setUpTestData()
, а не перед каждым тестом, и использует транзакции для очистки базы данных перед каждым тестом.
Django JWT Token auth
|
|