Как сказал Стивен, вы Assert
против Mock NewsRepository в приведенном выше коде.
Идея насмешки состоит в том, чтобы изолировать тестируемый код и создавать подделки для замены их зависимостей .
. Вы используете репозиторий Mock NewsRepository для проверки чего-то, что использует INewsRepository
, в вашем случае вы упоминаете NewsService
;NewsService
будет использовать ваш макет INewsRepository
.
Если вы ищете в своем решении что-либо, использующее INewsRepository.FindAll (), вы создадите репозиторий Mock для тестирования этого кода изолированно.
Если вы хотите протестировать что-то, что вызывает ваш уровень Service, вам нужно будет смоделировать NewsService
.
Кроме того, как сказал Стивен, для NewsRepository
не нужно иметь копиюсам вводится IoC, поэтому:
public class NewsRepository : INewsRepository
{
private readonly INewsRepository newsRepository;
public NewsRepository(INewsRepository newsRepository)
{
this.newsRepository = newsRepository;
}
public IEnumerable<News> FindAll()
{
return null;
}
}
должно стать:
public class NewsRepository : INewsRepository
{
public IEnumerable<News> FindAll()
{
return null;
}
}
Если у вас есть функциональность в вашем методе FindAll (), который требует тестирования, вы можете смоделировать объектычто они используют .
В качестве точки стиля из великого Art Of Unit Testing инициализация фиктивных объектов лучше всего исключать из метода Setup и выполнять вспомогательным методомвызывается в начале метода.Поскольку вызов программы установки будет невидимым и сделает инициализацию макета неясной.
В качестве еще одной точки стиля из этой книги предлагается следующее соглашение об именовании модульных тестов: " MethodUnderTest_Scenario_ExpectedBehavior ",Таким образом,
FindAll_should_return_correct_news
может стать, например:
FindAll_AfterAddingTwoNewsItems_ReturnsACollectionWithCountOf2
Надеюсь, это сделает подход более понятным.