Написание 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
| |