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

Question

如果我的问题太基础，很抱歉。

我有一组 Web 服务（使用 .Net WebApi 开发）。这些服务是业务层或数据访问层的 API。这些 API 可能依赖于其他服务或数据库本身。

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

1. 由于业务层 API 依赖于数据访问服务或其他服务，如果我只编写单元测试来调用业务 API，那么它会调用数据访问 API。这是否是编写单元测试用例的正确方法？还是应该在单元测试中注入所有依赖对象？我认为前者是集成测试而不是单元测试。

2. 我是否应该为数据访问层编写单元测试？我查看了这个链接（编写数据访问代码的测试：单元测试是浪费），其中说 DAL 不需要进行单元测试。我是否仍然应该为数据访问层编写测试？我认为这将是集成测试而不是单元测试？

- Atul Sureka

---

对于第二点，我认为这取决于你的数据访问层中有多少业务逻辑。如果有可测试的逻辑，单元测试可以帮助使代码更加可靠。如果数据访问层只是执行简单的CRUD操作，我认为进行单元测试没有意义。对于第一点，最佳实践建议所有服务都应该实现接口。如果UI -> 业务 -> 数据访问层，你可能会有IBusiness和IDAL，通过UT模拟和伪造使每个接口可测试。 - Todd Sprang

我认为人们在追求听起来“正确”或“聪明”的时候，会过于纠结于术语。拥有能够防止回归的测试是一件好事。无论这些测试是否涉及数据库，在大局上并不重要。拥有测试==好，没有测试==坏。话虽如此，如果你想要纯粹的单元测试，你应该使用伪造实现注入所有依赖项。我喜欢FakeItEasy，但也有其他框架可以帮助你做到这一点。如果你的数据访问层执行超出读取和返回数据的逻辑，那么你应该对其进行测试。 - Craig W.

Answer 1

问题1:

我认为如果你想要进行TDD，这不是"正确"的方式，因为正如你所说，你将执行集成测试。再次强调，也许你并不想进行TDD，集成测试对你来说已经足够好了，但回答这个问题:这不是测试你的代码的适当方式。

---

问题2

我认为这要取决于你的数据访问层中有什么。例如，如果你实现了存储库，那么你可能需要编写一些测试。

保存方法

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

错误和异常

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

另一方面

如果你的数据访问层只是一些包装了不可模拟 ORM 的类，并且你没有在其中编写任何逻辑，那么也许你不需要测试，但似乎这种情况并不经常发生，你几乎总会有一些可能出错的逻辑需要测试。

- Fabio Salvalai