Django, когда использовать метод teardown

Согласно документам:

TestCase, с другой стороны, не обрезает таблицы и не перезагружает начальные данные в начале теста. Вместо этого он включает тест кода в транзакции базы данных, которая откатывается в конце контрольная работа. Он также запрещает тестируемому кодексу выдавать какие-либо фиксации или откаты в базе данных, чтобы убедиться, что откат в конец теста восстанавливает базу данных в исходное состояние. В чтобы гарантировать, что весь код TestCase начинается с чистого база данных, тестовый бегун Django запускает все тесты TestCase, прежде чем любые другие тесты (например, доктрины), которые могут изменять базу данных без восстанавливая его в исходное состояние.

Итак, если у меня есть тест, который выглядит так:

class GeneralUserCreateTest(TestCase):

    def setUp(self):
        create_roletypes()
        create_permissiontypes()
        self.client = Client()
        self.event = create_event()

    def test_create(self):
        create_url = reverse('event_user_signup', args=[self.event.slug])

        post_data = {
            'signup-account-email': '[email protected]',
            'signup-account-password': 'foobar',
            'signup-account-password2': 'foobar',
            'signup-account-first_name': 'Foo',
            'signup-account-last_name': 'Bar',
        }
        response = self.client.post(create_url, data=post_data)
        self.assertEqual(response.status_code, 302)

        # check creation of user object
        self.assertEqual(User.objects.filter(email=post_data['signup-account-email']).count(), 1)
        user = User.objects.get(username=post_data['signup-account-email'])

        # user and profile objects created
        self.assertEqual(User.objects.all().count(), 1)
        self.assertEqual(Profile.objects.all().count(), 1)

        # get the first user and profile object to test against submitted field
        user = User.objects.all()[0]
        profile = Profile.objects.all()[0]
        role = Role.objects.filter(event=self.event, profiles=profile)[0]
        self.assertEqual(role.roletype.name, 'General')
        self.assertEqual(user.username, post_data['signup-account-email'])
        self.assertEqual(user.email, post_data['signup-account-email'])
        self.assertEqual(profile.first_name, post_data['signup-account-first_name'])
        self.assertEqual(profile.last_name, post_data['signup-account-last_name'])

Необходимо ли все-таки запустить метод teardown или класс TestCase позаботится об этом? Если да, то когда следует использовать метод teardown, учитывая доступность класса TestCase?

Ответ 1

Для целей базы данных tearDown довольно бессмысленно, потому что каждый тест выполняется в транзакции. Однако не все в тесте включает базу данных. Вы можете протестировать создание/чтение файлов, отключение процессов, открытие сетевых подключений и т.д. Эти типы вещей обычно требуют, чтобы вы "закрыли" их после завершения. Для этого используется tearDown, т.е. Очистка материала от вашего метода setUp, не связанного с базой данных. (Хотя, если вы фактически подключались к базе данных, то есть, поскольку фактические тесты Django должны делать, чтобы все данные DBAPI работали правильно, вам также нужно будет очистить их.)

Ответ 2

Я работал над проектом, который обрабатывал некоторые загрузки файлов, и мне нужно было удалить файлы, созданные с помощью теста, и метод tearDown был очень полезен в этой ситуации.

import shutil

#....
#....

    def tearDown(self):
        shutil.rmtree(settings.UPLOAD_ROOT)

Ответ 3

Если вы используете альтернативную базу данных, такую как MongoDB или Redis, и вам нужно загрузить в набор исходных данных ( "коллекция" ), вам также необходимо переопределить метод tearDown.

См. http://www.belchak.com/2011/02/07/unit-testing-django-with-a-nosql-backend/

В общем, django.test.TestCase выполняет полную загрузку базы данных в начале каждого новый тест. Это означает, что нам не нужно вручную удалять объекты в нашем tearDown, как упоминал выше Крис Пратт. Следующий тестовый наборUp гарантирует, что база данных будет чистой.

Однако, если мы используем doctests и unittest.TestCase, перед запуском тестов снова не будет сбрасываться база данных. В начале теста база данных будет в любом состоянии предыдущего тест влево. Это означает, что любые блуждающие данные, оставленные предыдущим запуском, вызовут конфликт. Поэтому, если мы используем doctests или unittest.TestCase для наших тестов django, очистка может быть хорошей практикой.

Наконец, в более сложных сценариях также может быть целесообразно намеренно сохранить тестовую базу данных для поиска определенных ошибок unit test.