Юнитест в Джанго. Какова связь между классом TestCase и методом

Question

Я занимаюсь модульным тестированием в Django. Какова связь между классом TestCase и фактическим методом в этом классе? Какова наилучшая практика для организации этих вещей?

Например, у меня есть

class Test(TestCase):
    def __init__(self):
        ...
    def testTestA(self):
        #test code

    def testTestB(self):
        #test code

Если я организую таким образом:

class Test1(TestCase):
    def __init__(self):
        ...
    def testTestA(self):
        #test code

class Test2(TestCase):
    def __init__(self):
        ...
    def testTestB(self):
        ...

Что лучше и в чем разница?

Спасибо!

Answer 1

1. Вы редко пишете __init__ для TestCase.Поэтому вычеркните это из своей ментальной модели юнит-тестирования.

2. Вы иногда пишете setUp и tearDown.Однако Django автоматизирует большую часть этого процесса, и вы часто просто предоставляете статическую переменную fixtures=, которая используется для заполнения тестовой базы данных.

По существу, что такое тестовый пример?

Тестовый пример - это «прибор» - конфигурация тестируемого устройства, которую вы можете затем применить.В идеале каждый TestCase имеет метод setUp, который создает один прибор.Каждый метод будет выполнять манипуляции с этим прибором и утверждать, что манипулирование сработало.

Однако.В этом нет ничего догматического.

Во многих случаях - особенно при работе с моделями Django - там просто не так много интересных манипуляций.

Если вы не переопределите saveв модели вам не нужно проводить CRUD-тестирование.Вы можете (и должны) доверять ORM.[Если вы не доверяете этому, то получите новую платформу, которой вы делаете доверяете.]

Если у вас есть несколько свойств в классе моделей, вы можете не захотеть создаватьотдельный метод для проверки каждого свойства.Возможно, вы захотите просто протестировать их последовательно в одном методе одного TestCase.

Если, OTOH, у вас действительно сложный класс с большим количеством изменений состояния, вам понадобится отдельный TestCase, чтобы настроить один объектсостояние, манипулируйте им в другое состояние и утверждайте, что все изменения вели себя правильно.

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

Сводка

Представьте TestCase как "Настройка "или" Контекст ", в которой будут выполняться тесты.

Думайте о каждом методе как о выражении" when_X_should_Y ".Некоторые люди предлагают такое имя («test_when_x_should_y»), поэтому метод будет выполнять «X» и утверждать, что «Y» был ответ.

Answer 2

Трудно ответить на этот вопрос относительно правильной организации случаев A и B и методов испытаний 1, 2 и 3 ...

Однако разбиение тестов на тестовые случаи служит двум основным целям: 1) Организация тестов вокруг некоторых логических групп, таких как CustomerViewTests, OrdersAggregationTests и т. Д.

2) Совместное использование одних и тех же методов setUp () и tearDown () для тестов, требующих такой же настройки, ну и настройки.

Дополнительную информацию и примеры можно найти в Документация unitTest .