我的团队继续在我们编写的单元测试中发现越来越多的价值。我们通常不会对应用程序的数据访问层进行单元测试，因为它们不包含“逻辑”。根据我的经验，由于让开发人员编写与实时数据库（或 Web 服务）对话的单元测试，我们遇到了严重的性能问题和不可重现的错误，因此越来越多的开发人员正在创建向这些数据库提供数据的模拟单元测试。
采用这种方法提高了测试速度，并将测试隔离到逻辑上，而不是同时测试连接/检索。我想知道这听起来是否合理，可以作为编码标准执行。我缺少的关于单元测试实时数据库/网络服务的优点/缺点是什么？
【问题讨论】：
标签： .net unit-testing continuous-integration coding-style
您的应用程序的数据库和 Web 服务部分也应该进行测试，但根据定义，它们不会是单元测试，而是集成测试。这些测试将与您的单元测试分开并且运行频率较低，但会提供非常有价值的早期缺陷检测。
【讨论】：
我通常将unit test 视为单独测试单个类或模块的东西。因此，我尽量避免让单元测试了解实时系统或外部资源——我倾向于在单元测试中避免这种依赖——或者模拟它们。
Integration tests 是另一回事。集成测试应该避免模拟资源，因此可能确实需要实时数据库或服务来支持它。您所描述的听起来可能是集成测试而不是单元测试。
在某些情况下，最好模拟集成测试所需的服务 - 但如果可能，我会尽量避免这种情况，因为我不相信模拟能够反映真实事物的行为。对我来说，集成测试实际上应该测试系统中组件的集成。
【讨论】：
不应该使用实时数据进行单元测试。
即使您想开始进行集成测试，也不要从实时数据开始。
应始终针对开发数据或模型数据进行集成测试。首选方法是拥有一个从实时数据发布的开发系统，或者使用 sql 脚本生成一组完整的数据供您进行测试。
【讨论】：
IMO 您可能错过了，如果您在测试中使用数据库/WS，这不是单元测试，而是集成测试。
【讨论】：
任何构建验证测试都应尽可能完整。如果你有一个依赖外部资源的函数调用，你必须确保整个系统运行正常。
对连接到数据库的函数进行专门的单元测试可能会产生问题，因为这些函数可能会产生副作用，例如插入数据。这些副作用可能会导致返回值发生变化。
【讨论】：
根据我的经验，应该在多个级别上进行测试：
每个测试都有其用处。
【讨论】：
很抱歉，许多开发人员都忽略了您还需要对数据库进行单元测试这一事实。我同意模拟类“A”和数据库之间的连接，但是在某些时候，您将创建一个使用某些数据访问技术（例如 ADO.NET）的类，并且您需要对其进行测试它确实有效。
现在，通过保持这些测试小而有针对性，您可以更轻松地防止副作用，并确保数据库的正确初始条件。但事实是您必须测试这样的代码，否则您正确测试的业务逻辑最终会处理不好的数据。
【讨论】：