Это нормальное юнит-тестирование убирает все поведение из моих классов?

Question

Я начинаю новый проект и хочу использовать модульное тестирование.

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

Мой вопрос: в моем бизнес-классе нет абсолютно никакого кода!(как Клиент)

Это нормально?это нормально даже без юнит-теста?какой код вы бы поместили в класс типа «Клиент»?

Answer 1

Нет, для меня это не звучит нормально - если только вы не в самом начале своего проекта, и Customer пока что просто скелет, и вы знаете , он получит больше функциональности по сравнению свремя.

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

Это не ошибка модульных тестов.Модульные тесты никоим образом не заставляют создавать тупые классы без реальной функциональности.

Answer 2

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

Я вижу, что это случается чаще всегочасто с людьми, начинающими с доменного дизайна, а также когда люди используют шаблоны проектирования, такие как MVVM - вся логика попадает в службы, контроллеры и менеджеры (которые сами по себе являются запахом IMO), а модель ядра домена становится очень анемичным наборомDTO.

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

Answer 3

При четком проектировании может возникнуть ситуация, когда некоторые классы являются просто агрегатами данных.Это часть шаблона MVC, где модели не должны содержать много логики.Однако, если у вас нет абсолютно никакого кода в ваших классах, что-то серьезно не так.

Для меня это звучит так, как будто вы пытаетесь внедрить какую-то зависимость, но вы вводите не только зависимости, а скорее все.Это далеко уходит от паттерна, поэтому может стать его собственным анти-паттерном.