Можем ли мы использовать более одного макетного объекта в модульном тестировании?

Question

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

Answer 1

Вы должны добавить столько mocks, сколько необходимо, чтобы изолировать тестируемый вами класс.Вам нужен макет для каждой зависимости, который не должен быть частью теста.

Иногда вы объединяете два или три класса в тесте для простоты, потому что они создают что-то вроде компонента и сильно связаны.Все остальное должно быть высмеяно.

Я знаю, что эта "лучшая практика" заключается в том, чтобы иметь только один макет, и также не понимаю этого.В наших модульных тестах у нас есть много макетов, некоторые макеты окружающей среды настраиваются тестовым фреймворком, который я написал (например.TransactionService, SecurityService, SessionService).Есть только одна вещь, которую следует учитывать, как уже упоминал Гишу в своем ответе, многие насмешки являются признаком высокой зависимости.Вам решать, когда этого будет слишком много.У нас много небольших интерфейсов, что требует большого количества макетов в тестах.

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

• Это сильно связанная часть тестируемого класса, такая как внутренний класс, частный класс и т.д.
• Это обычный класс .NET framework, такой как коллекция и тому подобное
• Вы хотите написать интеграционный тест, чтобы точно протестировать взаимодействие с этим классом.(Вы по-прежнему издеваетесь над всем остальным, и у вас по-прежнему есть модульные тесты для каждого задействованного класса изолированно.)
• Просто слишком дорого издеваться над определенным классом.Будьте осторожны, решая, что это слишком дорого, mocks кажутся сложными в настройке, но оказываются проще простого по сравнению с проблемами ремонтопригодности, которые возникнут у вас при использовании реальных классов.Но есть некоторые фреймворки и технологии, которые не реализуются в интерфейсах, и их очень трудно смоделировать.Если размещать классы этого фреймворка за вашим собственным интерфейсом слишком дорого, вам нужно работать с ними в тестах.

Answer 2

В модульном тестировании может быть несколько макетов, в зависимости от контекста.

Однако я думаю, что "статьи" могут намекать на то, что

• предотвращение чрезмерно издевательский.Когда модульный тест высмеивает всех сотрудников, вы оставляете дверь открытой;сценарий может потерпеть неудачу, если вы замените реальных сотрудников.Сводя к минимуму количество макетов и используя реальных коллаборационистов, насколько это возможно, вы минимизируете этот риск.
• Высокое Сцепление оповещения:Если вам приходится издеваться над множеством сотрудников, чтобы написать модульный тест, это может быть запах дизайна, указывающий на то, что у вас высокая степень сцепления.

Answer 3

Я не уверен, на какие статьи вы ссылаетесь, но обычно у меня есть один макет объекта на зависимость для тестируемого класса.