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和。进入控制器......

那么简单地将存储库方法作为一个单元测试来测试我关心测试的所有实际内容是否很正常？或者我通过在存储库方法中拥有所有获取逻辑来错过一些更大的图片？

Answer 1

欢迎追逐100％测试覆盖率的风车：）

你是对的，在单元测试一个实际上并不包含任何逻辑的控制器方法时，没有 ton 值。（在世界的某个地方，鲍勃叔叔只是把他的咖啡洒了。）虽然有一些......

通过明确定义期望（在这种情况下，基本上与模拟交互），您的测试将告诉您此方法是否会发生变化，这本身就是值得了解的事实。尤其是在较大的团队中，流氓的错误可能会被忽视。
如果由于方法本身处于大量流失状态，必须不断更改此方法的测试，则表明该方法可能对组织中的太多角色负责，或者可能以某种方式不同责任的融合。如果没有良好的测试覆盖率，这类事情往往会被忽视，而且这也是导致错误进入的一种方式。

最终，这是你，开发者的判断。编写测试的成本可能超过拥有它的价值。（虽然，从我上面的第二点来看，如果成本很高那么本身可能表明设计出了问题，可能需要进行一些重构......这对测试来说更容易。）

就个人而言，我会为这种方法编写测试。它不应该改变，如果它确实改变了，我想要痛苦地意识到这一点，所以我可以适当地重构。也许通过将这些存储库交互中的一些移动到可以测试的单个原子业务方法中，让控制器操作除了调用该业务方法的模拟之外什么都不做。

Answer 2

Take和Where事物应该在存储库中进行测试，你真正需要在Controller中测试的是它正确调用存储库并处理repo以正确的方式返回。

您的存储库应该有多详细？测试问题

2 个答案: