Определяй компоненты на основе контрактов, используя интерфейсы и абстрактные классы. Такой подход позволяет фреймворкам для мокирования легко создавать замены зависимостям во время тестирования. Программируя через интерфейсы, а не через конкретные реализации, ты получаешь гибкое мокирование и снижаешь связанность между компонентами.
Избавься от использования статических методов и классов в своём дизайне. Статические элементы нельзя легко замокировать, потому что их нельзя переопределить или заменить. Это ограничение серьёзно урезает твою способность изолировать код во время юнит-тестов. Вместо этого используй методы экземпляров, которые можно замокировать через dependency injection.
Применяй Dependency Injection (DI), чтобы передавать внешние зависимости в свои классы. Вместо того чтобы классы создавали свои собственные зависимости, передавай их как параметры конструктора или свойства. Этот паттерн решает две критически важные задачи:
Следование этим практикам даёт несколько преимуществ:
Придерживаясь этих лучших практик — используя интерфейсы, избегая статики и реализуя DI — ты создаёшь кодовую базу, которая естественно тестируется и поддерживает надёжные стратегии юнит-тестирования.
Статические методы в C# могут быть эффективно смокированы в unit тестах большинством современных mock фреймворков, если они отмечены как virtual.
Новый — ещё не проверен сообществом
Вы