Подтвердить что ты не робот

Django setUpTestData() vs. setUp()

Django 1.8 поставляется с реорганизованным TestCase, который позволяет инициализировать данные на уровне класса с помощью транзакций и точек сохранения через setUpTestData(). Это контрастирует с unittest setUp(), который выполняется перед каждым тестовым методом.

Вопрос: Каков прецедент для setUp() в Django теперь, когда setUpTestData() существует?

Я ищу объективные ответы на высоком уровне, поскольку в противном случае этот вопрос будет слишком широк для.

4b9b3361

Ответ 1

Весьма часто встречается код настройки, который не может быть запущен как метод класса. Одним примечательным примером является тестовый клиент Django: вы можете не захотеть повторно использовать один и тот же экземпляр клиента в тестах, которые в противном случае совместно используют большую часть одних и тех же данных, и действительно, экземпляры клиента, автоматически включаемые в подклассы Django SimpleTestCase, создаются для каждого метода теста, а не для всего класса. Предположим, у вас был тест из мира до Django 1.8 с методом setUp подобным этому:

    def setUp(self):
        self.the_user = f.UserFactory.create()
        self.the_post = f.PostFactory.create(author=self.the_user)
        self.client.login(
            username=self.the_user.username, password=TEST_PASSWORD
        )
        # ... &c.

Вы можете испытать желание модернизировать тестовый пример, изменив setUp на setUpTestData, @classmethod декоратор @classmethod сверху и изменив все self на cls. Но это не удастся с AttributeError: type object 'MyTestCase' has no attribute 'client' ! Вместо этого вы должны использовать setUpTestData для общих данных и setUp для setUp для каждого метода тестирования:

    @classmethod
    def setUpTestData(cls):
        cls.the_user = f.UserFactory.create()
        cls.the_post = f.PostFactory.create(author=cls.the_user)
        # ... &c.

    def setUp(self):
        self.client.login(
            username=self.the_user.username, password=TEST_PASSWORD
        )

Примечание: если вам интересно, что эта переменная f делает в коде примера, она взята из factoryboy - полезной библиотеки приспособлений для создания объектов для ваших тестов.

Ответ 2

Взято из этого учебного пособия: https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Testing#Views

setUpTestData() вызывается один раз в начале теста для настройки на уровне класса. Вы бы использовали это для создания объектов, которые не будут изменены или изменены ни в одном из методов тестирования.

setUp() вызывается перед каждой тестовой функцией для установки любых объектов, которые могут быть изменены тестом (каждая тестовая функция получит "свежую" версию этих объектов).

Ответ 3

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

[править]: SetUpTestData определяет состояние, в котором БД будет восстановлено после каждого теста, и делает это с помощью метода, который выполняется только один раз, откат транзакции выполняется за занавеской Django. Это не работает для кешей. Если вы хотите, чтобы кеш был одинаковым для каждого теста, вам нужно reset его между каждым тестом, поэтому потребность в setUp. Django может откатить DB, но не может откатить все.

(Спасибо, Брайан-оукли за предложение)