дизайн бизнес-класса для юнит-теста

Question

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

Мой бизнес-класс полон методов с похожей реализацией, такой как:

var rep=new NHrepository<ModelClass1>(Session);
rep.Where(x=>x.Field1==1).ToList();

Первая ошибка (с моей точки зрения) заключается в том, что мне не нужно использовать «new», а вместо этого использовать DI и добавить в параметры ctor INHrepository modelClass1Repository.

Если в моем классе у меня есть два или более хранилища разных моделей класса? Каждый должен быть в КТО? Или, возможно, бизнес-класс строится не по принципу SeparationOfConcern?

Answer 1

Один из широко используемых подходов - иметь n репозиториев в качестве параметров для ваших конструкторов, как вы уже подозревали

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

[Inject]
public IAbstractRepository<Company> companiesRepository { get; private set; }

[Inject]
public IAbstractRepository<User> usersRepository { get; private set; }

После этого Ninject может внедрить соответствующую реализацию вашего интерфейса в зависимости от сценария использования (например, поддельный репозиторий для тестирования или реальный репозиторий для производства)

Answer 2

Вы правы насчет внедрения зависимостей.

Кроме того, я настоятельно рекомендую прочитать Эффективная работа с устаревшим кодом , если вы планируете писать модульные тесты для своего устаревшего кода.

Answer 3

Ваш бизнес-класс должен иметь конструктор с 2 параметрами, по одному на каждый репозиторий. Ваш бизнес должен предоставлять 2 интерфейса, а ваша настойчивость должна обеспечивать их реализацию.