запах модульного теста

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

Вы также должны уметь делать большую часть из ваше издевательство в методе [SetUp] , а затем каждый тест просто изменяет одну или две вещи.

Для имитации нескольких интерфейсов у Rhino есть концепция MultiMock. Я считаю, что вам нужен синтаксис:

var mock = 
    MockRepository.DynamicMultiMock<MyType>(
              typeof(Interface1), 
              typeof(Interface2), 
              ....);

Это может быть признаком сильной связи, что, в свою очередь, подразумевает необходимость уменьшения зависимостей (что улучшит дизайн и тестируемость). Ориентировочно, у объекта должно быть не более 4-6 сотрудников. Все, что связано с этим, вызовет у меня тревогу.

Как предполагается использовать Mocks?

Для меня это звучит как непроверяемый код, а это запах :-(

Я бы рекомендовал прочитать http://misko.hevery.com/code-reviewers-guide/ . Автор является тренером, ответственным за обучение разработчиков Google в области тестирования. В статье он показывает, как можно писать тестируемый и непроверяемый код.

Рекомендуем также прочитать: Чистый код (Роберт К. Мартин) - основное внимание уделяется тому, как писать чистый (соответствующий тестируемому) код. Эффективная работа с устаревшим кодом (Майкл Фезер) - показывает способы взять под контроль непроверенный и непроверенный код.