.net 强制执行单元测试不应与实时数据库/Web服务对话是否合理？

我的团队继续在我们编写的单元测试中发现越来越多的价值。我们通常不会对应用程序的数据访问层进行单元测试，因为它们不包含“逻辑”。根据我的经验，由于让开发人员编写与实时数据库（或Web服务）对话的单元测试，我们遇到了严重的性能问题和不可再现的错误，因此越来越多的开发人员正在创建模拟，将数据提供给这些单元测试

---

采用这种方法提高了对逻辑的测试和隔离测试的速度，而不是同时测试连接/检索。我想知道作为一种编码标准，这听起来是否合理。关于单元测试，我所缺少的实时数据库/Web服务的优点/缺点是什么？

我通常将测试视为单独测试单个类或模块的东西。因此，我尽量避免让单元测试了解实时系统或外部资源——我倾向于在单元测试中避免这种依赖关系——或者模拟它们

是另一回事。集成测试应避免模拟资源，因此可能确实需要实时数据库或服务来支持它。您所描述的内容听起来可能是集成测试，而不是单元测试

---

在某些情况下，模拟集成测试所需的服务是可取的，但如果可能，我会尽量避免这种情况，因为我不相信模拟能够反映真实事物的行为。对我来说，集成测试实际上应该测试系统中组件的集成。

我想，如果在测试中使用数据库/WS，那么这不是单元测试，而是集成测试。

应用程序的数据库和Web服务部分也应该测试，但根据定义，它们将不是单元测试，而是集成测试。这些测试将独立于单元测试，运行频率较低，但将提供非常有价值的缺陷早期检测。

任何构建验证测试都应尽可能完整。如果您有一个依赖于外部资源的函数调用，则必须确保整个系统运行正常

---

针对连接到数据库的函数的特定单元测试的问题可能是有问题的，因为这些函数可能有副作用，例如插入数据。这些副作用可能会导致返回值发生更改

根据我的经验，测试应该在多个层次上进行：

• 在不需要外部数据的情况下检查类/模块正确性的单元测试
• 检查应用程序较大部分、从特定数据库/文件加载数据并验证结果（例如，通过比较输出文件）的系统测试。确保不更改这些数据库/文件，并确保每组测试有一个数据库/文件集
• 检查用户界面的手动测试

---

这些测试中的每一个都很有用。

很抱歉，但是许多开发人员都忽略了一个事实，即您也需要对数据库进行单元测试。我同意模拟类“A”和数据库之间的连接，但在某个时候，您将创建一个使用某些数据访问技术（例如ADO.NET）的类，并且您需要测试它是否实际工作

---

现在，通过保持这些测试的小型化和集中化，您可以更轻松地防止副作用，并确保数据库的初始条件正确。但事实是，您必须测试这些代码，否则经过适当测试的业务逻辑将使用糟糕的数据。

单元测试不应使用实时数据，句号

即使您想开始进行集成测试，也不要从实时数据开始

---

开始集成测试时，应始终针对开发数据或模型数据进行。首选的方法是拥有一个从实时数据发布的开发系统，或者使用sql脚本生成一组完整的数据供您测试

应尽可能避免方法/类中的副作用，例如使用依赖项注入。