когда не использовать макет

Question

У меня есть базовый класс, который зависит от другого класса для некоторого специального кэширования.Я также написал специальный класс кэширования.

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

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

Лучшей идеей может быть написание обоих тестов (с использованием mock и с использованием реального класса), но другим разработчикам может быть непонятно, почему я тестирую его дважды.

Должен ли я использовать mock здесь или настоящий класс?

Answer 1

Зачем вам издеваться над реальным классом, если он выполняет свою работу?

Мой совет:

• проверить возможности вашего класса в его тестовом примере, кроме кэширования,
• тестирование кэширования в кеше; тестовый пример

Меня это не смущает, поскольку тесты вашего класса кэша являются исчерпывающими: если кэширование приводит к проблемам, тесты кэширования должны провалиться, а не ваш внешний класс.

Answer 2

Я был в подобных ситуациях, когда у меня был класс в рабочем коде, который был подкреплен парой юнит-тестов.Эти модульные тесты создали фиктивные объекты для передачи в класс производственного кода.Это означало, что я смог запустить модульные тесты без каких-либо зависимостей.

Теперь мне также потребовалось использовать этот производственный класс как часть теста BDD (используя SpecFlow).Этот тип тестирования был большей интеграцией, так как я фактически создал реальный объект (вместо макета), который требовался производственному классу.

Так что из моего опыта я создал фиктивный объект только для модульных тестов, покасоздание реального объекта для моих интеграционных тестов.Хотя это очень субъективно, но для меня это сработало нормально.

Answer 3

Обычно базовый класс зависит от другого класса, не обязательно для кэширования, но для "присмотра за XYZ для меня".Сотрудничающий класс просто действует как хранилище.Тестируемый класс не должен знать или заботиться о том, что другие классы кэшируются - в противном случае у вас есть связывание там, которое вам, вероятно, не нужно.

Затем вы использовали бы интерфейс для выражения этого.Я обычно называю мой «ILookAfterXYZ» - я считаю, что этот шаблон именования действительно помогает мне понять, что мне помогает мой класс для совместной работы, - и высмеиваю это.

Кэширование - это проблема производительности, а неповеденческий.Я пришел к этому вопросу, потому что он помечен как «BDD», но я бы не стал использовать тесты в стиле BDD ни на единичном, ни на системном уровне, чтобы определить полезность таких вещей, как кэширование.Вместо этого пишите тесты производительности и используйте их, чтобы проверить, работает ли кэширование.