Comments 2
@Maxim_from_HW Огромное спасибо за очень взвешенную статью. Несравнимо лучше https://habr.com/ru/articles/837630/.
Чуток споткнулся о ваш собственный testcase, особенно когда в django есть "TestCase", "TransactionTestCase", "SimpleTestCase", "LiveServerTestCase", а так же не документированный SeleniumTestCase. Но видать так было проще.
Ну и объяснение отличия setUpTestData() и def setUpClass() не верное. Первое вызывается внутри второго, после проверок готовности базы данных и загрузки фикстур. (row 1466 django\test\testcases.py). в итоге setUpTestData просто способ что-либо еще сделать после того как масса тестовых данных попала в базу но перед запуском тестов.
Спасибо так же за общие замечания про тестирование, вот бы все тесто-авторы про это знали! Буду давать своим новичкам это статью для ознакомления! Успехов в тестировании!
Спасибо за комментарий!
Наш собственный тест кейс был указан как "отягощающее" состояние для тестов, у него широкий функционал и он продолжает пополняться. Поэтому, когда тестирование было только в начале разработки, применение тестовой среды для каждого теста не было проблемой. Со временем это стало занимать все больше и больше времени. Наш кастомный тест кейс как раз наследуется от TestCase, упомянутый вами.
Насчет разницы между setUpTestData() и def setUpClass() — в вашем определении не вижу противоречия с нашим. Да, def setUpClass() вызывается внутри setUpTestData(). Но так же он конфликтует с TransactionalTestCase, которые мы используем в тестировании. setUpTestData() такого конфликта не вызывает, поэтому именно его и выбрали
Автотесты на Django: менеджмент данных тестирования на монолите