Насколько подробно должен быть ваш репозиторий? Тестирование выдает

Question

В мой контроллер, у меня есть что-то вроде этого:

class HomeController 
{ 
    [AllowAnonymous] 
    public ActionResult Index() 
    { 
     HomeViewModel viewModel = new HomeViewModel(); 
     viewModel.FieldSearchCriteria = new SearchCriteria(); 
     viewModel.Blogs = this.unitOfWork.BlogRepository.GetAllPublishedBlogs(1, 2, "PublishDate", SortDirection.DESC, null).ToList(); 
     viewModel.FieldWanteds = this.unitOfWork.FieldWantedRepository.GetAllFieldWanteds(1, 2, "CreatedAt", SortDirection.DESC, null).ToList(); 
     viewModel.Fields = this.unitOfWork.FieldRepository.GetAllFeaturedPublishedFields(1, 4, "CreatedAt", SortDirection.DESC, null).ToList(); 
     viewModel.UserID = User.Identity.GetUserId(); 

     return View(viewModel); 
    } 
} 

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

Действительно ли это нормально, чтобы просто протестировать метод репозитория как единичный тест, где все фактические вещи I забота о тестировании происходит? .. Или я упускаю какую-то большую картину, имея всю логику извлечения из методов репозитория?

Answer 1

Добро пожаловать в погоне за ветряная 100% тестового покрытия :)

Вы правы, там не т значения в блоке тестирования метода контроллера, который фактически не содержит никакой логики. (Где-то в мире, дядя Боб просто пролил кофе.) Существуют некоторые, хотя ...

• Явно определяя ожидания (в данном случае взаимодействии с издеваешься, в основном), то ваш тест покажет, если этот метод когда-либо меняется, что само по себе заслуживает внимания. Особенно в больших командах, где ошибка мошенника может остаться незамеченной.
• Если тест для этого метода должен постоянно меняться, потому что сам метод находится под большим количеством оттока, это сигнал о том, что метод может отвечать за слишком много ролей в организации или каким-то образом может быть конвергенцией разные обязанности. Такие вещи часто могут остаться незамеченными без хорошего тестирования, и это может быть ошибкой, чтобы найти свой путь.

В конечном счете это решение суда, разработчика. Стоимость написания теста может перевесить ценность его наличия. (Хотя, по моему второму пункту выше, если эта стоимость высока, то сам может быть признаком того, что что-то не так с дизайном и может потребоваться некоторый рефакторинг ... что легче сделать с тестами.)

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

Answer 2

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