如何为依赖于其他服务或数据库的服务编写单元测试答案

【问题标题】：How to write unit test for service having dependency on other service or database如何为依赖于其他服务或数据库的服务编写单元测试
【发布时间】：2016-01-19 04:16:03
【问题描述】：

对不起，如果我问的是非常基本的问题，

我有一组网络服务（使用 .Net WebApi 开发）。这些服务要么是业务层 API，要么是数据访问层 API。这些 API 依赖于其他服务或数据库本身。

我想为它编写单元测试用例。我有以下问题

由于业务层 API 依赖于数据访问服务或其他一些服务。如果我编写单元测试只是为了调用业务 API，那么它将调用数据访问 API。这是编写单元测试用例的正确方法吗？还是应该用单元测试注入所有依赖对象？我认为之前的测试是集成测试而不是单元测试。
我应该为数据访问层编写单元测试吗？我检查了这个链接 (Writing tests for data access code: Unit tests are waste)，它说 DAL 不需要单元测试。我是否还应该为数据访问层编写测试。我认为这将是集成测试而不是单元测试？

【问题讨论】：

对于 2，我认为这取决于您的 DAL 中有多少业务逻辑。如果有可测试的逻辑，那么单元测试可以帮助使代码可靠是理所当然的。如果 DAL 只是做简单的 CRUD 操作，我认为这对 UT 没有意义。对于 1，最佳实践建议您的所有服务都应该实现接口。如果 UI -> Business -> DAL，你可能有 IBusiness 和 IDAL，使得每个接口都可以通过 UT mocks 和 fakes 进行测试。
我认为人们过于沉迷于术语，希望听起来“正确”或“聪明”。拥有可以防止回归的测试是一件好事。这些测试是否涉及数据库或不涉及数据库在总体方案中并不重要。有测试==好，没有测试==坏。话虽如此，如果您想要纯单元测试，您应该使用伪造的实现注入所有依赖项。我喜欢 FakeItEasy，但还有其他框架可以帮助您做到这一点。如果您的 DAL 执行的逻辑超出了读取和返回数据的范围，您应该对其进行测试。

标签： c# .net unit-testing integration-testing moq

【解决方案1】：

问题一：

我会说，如果您想进行 TDD，那么这不是“正确”的方式，因为正如您所说，您将执行集成测试。再说一次，也许你不想想要做 TDD 并且集成测试对你来说已经足够好了，但是要回答这个问题：这不是 **unit-**test 的正确方法你的代码。

问题 2

我会说这取决于您在数据访问层中拥有什么。例如，如果您实现存储库，您可能需要编写一些测试。

保存方法

您要确保给定从存储库中检索到的实体，编辑该实体的某些属性并保留更改实际上会保存修改，而不是创建新实体。现在：您可能认为这是一个集成测试，但这实际上取决于您的代码设计得有多好。例如，您的存储库可能只是低级 ORM 之上的额外逻辑层。在这种情况下，在测试 save 方法时，您将断言在注入到您的存储库中的 ORM 服务上使用正确的参数调用正确的方法。

错误和异常

在访问数据时，可能会出现数据库连接中断、数据格式不符合预期、反序列化等问题。如果您想提供一些良好的错误处理并可能创建自定义异常并根据上下文向它们添加更多信息，那么您肯定需要编写测试以确保传播正确的信息

另一方面

如果您的 DAL 只是包装了不可模拟 ORM 的几个类，并且您没有任何逻辑，那么也许您不需要测试，但似乎这种情况不会经常发生，你几乎总会有一些可能出错的逻辑并且你想测试。

【讨论】：