Вы должны добавить столько макетов, сколько необходимо, чтобы изолировать тестируемый класс. Вам нужна макет для каждой зависимости, которая не должна быть частью теста.
Иногда вы помещаете два или три класса вместе в тест для простоты, потому что они создают что-то вроде компонента и сильно связаны. Все остальное надо издеваться.
Я знаю эту «лучшую практику», чтобы иметь только одну насмешку, а также не понимаю ее. В наших модульных тестах у нас есть много макетов, некоторые макеты среды настраиваются с помощью инфраструктуры тестирования, которую я написал (например, TransactionService, SecurityService, SessionService). Есть только одна вещь, которую следует учитывать, поскольку Гишу уже упоминал в своем ответе, что многие насмешки являются признаком высокой зависимости. Вам решать, когда это слишком много. У нас много небольших интерфейсов, которые требуют много проверок в тестах.
Чтобы перевернуть свой ответ, вы должны не издеваться над зависимостью, когда:
- Это высокосвязанная часть тестируемого класса, такая как внутренний класс, закрытый класс и т. Д.
- Это распространенный класс .NET Framework, такой как Collection и тому подобное
- Вы хотите написать интеграционный тест, чтобы точно проверить взаимодействие с этим классом. (Вы все еще издеваетесь над всем остальным, и у вас все еще есть модульные тесты для каждого участвующего класса в изоляции.)
- Это просто дорого издеваться над определенным классом. Будьте осторожны, решив, что это слишком дорого, макеты кажутся сложными в настройке, но они оказываются несложными по сравнению с проблемами сопровождения, которые у вас возникнут при использовании реальных классов. Но есть некоторые фреймворки и технологии, которые не реализуются на интерфейсах и которые очень трудно подделать. Если слишком сложно размещать эти классы каркаса за собственным интерфейсом, вам нужно жить с ними в тестах.