Писать модульные или интеграционные тесты -- дело вкуса, тем более, что четкой границы между ними нет -- ведь функциональность одного "юнита" может со временем "расползтись" по разным. И таки да, если уж Вы используете моки, то Вы, в каком-то смысле, тестируете не фичи, а способ их реализации. Частично с этим позволяет бороться мок-контейнер. А так -- дело вкуса. Я лично предпочитаю обходиться без репозиториев вообще, а в случае сложных запросов использовать Specification Objects -- тогда тестировать можно как с помощью тестовой базы, так и используя вручную изготовленный IQuerable.

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

Здравствуйте, Аноним, Вы писали:

А>Добрый день. Вопрос по unit тестам.
А>Имеется asp.net mvc приложение, где бизнес логика реализована в виде классов менеджеров, которые в свою очередь тянут данные из классов репозиториев.
А>Репезитории в менеджере инициализируются с помощью инъекции ioc unity через интерфейсы в конструкторе.
А>Вопрос в том, как правильно тестировать методы менеджера.
А>На данный момент, для тестирования какого либо метода менеджера, требуется сначало mock-нуть репозитории, создать менеджер с этими фейковыми репозиториями, подменить вызовы методов репозиториев, которые используются в тестируемом методе менеджера, подменить методы менеджера вызываемые в тестируемом методе.
А>Т.е получается для того что бы написать тест, нужно знать как написан тестируемый метод, т.е по сути тестируется не результат выполнения, а его код.
А>Мне кажется что этот подход полностью не верно, и тестировать метод нужно по стратегии черного ящика? Подскажите как правильно писать тесты в таких случаях.
А>спасибо