我们正在运行一个项目，在开发开始很久之后我们就开始采用测试驱动设计。
我们有单元测试和集成测试。集成测试在真实数据库上运行，在测试运行之前以已知状态初始化。
当我们编写测试时，我们开始注意到，即使对于可以以“标准方式”进行测试的类，在隔离和使用模拟对象的情况下，它实际上变得更快、更干净(阅读:更短且更容易理解的代码) 只使用真实的对象/服务直接与数据库对话，而不是用复杂的模拟对象设置使测试类困惑。
这种做法有什么问题吗？
最佳答案
一点问题都没有。相反，根据我的经验，我认为支持单元测试是错误的。您的团队对测试“变得更快、更干净”的看法与我多年前和从那时起的看法相同。
我什至会建议您完全放弃单元测试，并继续投资于集成测试。我这样说是因为有人开发了一个带有非常复杂的模拟 API 的测试库，多年来一直怀疑孤立的单元测试，然后最终得出集成测试的结论(在编写了两种类型的许多测试之后) 如此好多了。
不过，有一个更正:单元测试“隔离并使用模拟对象”不是“标准方式”。您可能知道，Kent Beck 是 "father" of TDD和 JUnit 的发明者。但是你猜怎么着，Kent 在他的 TDD 单元测试中根本没有使用模拟。严格来说，发明 TDD 的人编写的“单元”测试更接近于集成 测试，因为它们没有努力将被测单元与其依赖项隔离开来。 (这是对单元测试的常见误解。有关准确定义，请参阅 Martin Fowler 的 this article。)
关于unit-testing - 支持集成测试而不是单元测试是错误的吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11629265/