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

本文关键字：测试 问题 存储 | 更新日期: 2023-09-27 17:56:56

在我的控制器中，我有这样的东西：

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 );
    }
}

我已经在我的存储库中放置了非常具体的方法，以便我可以在整个应用程序中重用它们......但是，由于不使用诸如.哪里和.进入控制器内部...

那么简单地将存储库方法作为单元测试进行测试是很正常的吗，其中我关心的所有实际测试都发生了?..还是我错过了一些更大的图景，因为我将所有获取逻辑都放在存储库方法中？

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

欢迎追逐100%测试覆盖率的风车:)

你是对的

，对实际上不包含任何逻辑的控制器方法进行单元测试没有太多价值。 （在世界的某个地方，鲍勃叔叔刚刚把咖啡洒了。 不过，有一些...

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

归根结底，这是您（开发人员）的判断。 编写测试的成本可能超过拥有它的价值。 （不过，根据我上面的第二点，如果成本很高，那么这本身可能表明设计出了问题，可能需要一些重构......这更容易通过测试完成。

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

应该在存储库中测试"获取"和"位置"，您真正需要在控制器中测试的是它是否正确调用存储库并以正确的方式处理存储库的返回。

相关文章：