При модульном тестировании, как следует обрабатывать тестирование инициализации объектов?

#unit-testing #testing #tdd #automated-tests

#модульное тестирование #тестирование #tdd #автоматизированные тесты

Вопрос:

Итак, с большинством утилит модульного тестирования, с которыми я сталкивался, вы обычно получаете доступ к какой-либо функции SetUp() и TearDown() . Хотя я вижу, что это очень удобно практически для каждого модульного теста, мне было интересно, как следует обрабатывать тестирование инициализации объектов? Я имею в виду, что почти во всех других тестах вы просто позволяете функции SetUp() обрабатывать это. Однако в большинстве базовых утилит тестирования, с которыми я работал, SetUp() вызывается перед каждым тестом. Мне было интересно, выполняете ли вы просто тестирование инициализации в функции SetUp(), следует ли создать собственную эквивалентную функцию SetUp(), которая вызывается явно в начале тестов, не связанных с тестированием инициализации, или есть какая-то другая общепринятая практика, о которой я не упоминал?

Ответ №1:

Инициализация объекта выполняется конструктором, поэтому «тестирование инициализации» означает «тестирование конструкторов». При тестировании обычного метода мутатора вы должны выполнить интересующий метод, а затем сделать утверждения о состоянии объекта впоследствии. Для конструктора это то же самое. Единственное отличие от тестирования обычного метода, если вы создаете тестовые приспособления в своем setUp() методе, заключается в том, что методы тестирования сами не вызывают конструктор, а полагаются на вызов в методе set up .

Тем не менее, я отошел от стиля ThingTest , когда класс, который тестирует class Thing , имеет тестовые приспособления class Thing . Вместо этого я создаю объекты класса Thing непосредственно в методах тестирования, используя параметризованные тесты для уменьшения дублирования кода. Я считаю, что это позволяет избежать запаха таинственного гостевого кода.

Ответ №2:

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