我曾参与一个项目，其中一名开发者想要在测试中模拟数据库“为了性能，因为数据库很慢”。我差点气炸了。更有趣的是，这一切都是假设的，但被当作事实。我们甚至还没有编写测试，所以无法判断它们是否真的慢。没有任何测量，没有定义性能预算，也没有写出所谓的慢测试的原型来证明这一点。我们最终编写了——开玩笑地说——不到100个测试，其中几乎所有的测试都访问了数据库，包括一些完整的集成测试，而整个测试套件只用了几秒钟就完成了。我支持以尊重性能作为工程价值的方式进行构建，但我们似乎在某个地方迷失了。
源讨论在担任 Mockito 维护者10年后决定卸任原帖 214 条评论 · 导入时统计90%的时间（或更多）：你不需要。在正确设置的测试中，真正的东西已经很好了。文件I/O很快，我只需要一个在临时目录中的测试文件。数据库很快，我只需要一种简单的方式来设置我的模式。有时候我需要隔离，但通常不需要。
完整原文把你的经验，加入这段讨论。
> 我几乎要发疯了。 希望有一天你能回到那个状态，意识到当时是多么不成熟的态度。
完整原文我喜欢使用mock的唯一原因是你可以从头到尾定义所有数据对象，并像在纸上写出来一样看到整个工作流程，而不需要打开一堆文件或四处跳转。只需从上到下，就能看到所有应该存在的对象以及它们的顺序
完整原文我喜欢Mockito，它很有用，但我永远无法理解为什么要mock数据库相关的内容。 为什么要伪造它，而不用集成测试来测试真实的情况呢。 我见过你明显有的东西。mock的ResultSets，mock的JDBC模板。"当你得到SQL时，它应该是一个特定的字符串。这些参数应该被设置。等等。" 这太费劲了。而且毫无意义。要检查的SQL从哪里来？复制粘贴，这样无法发现语法错误。 测试数据在每个结果中都被伪造了。你无法测试外键。 这真是个坏主意。你说得对。我觉得有些人在mock方面过于反对了。是的，它被滥用，但这不是工具的错。 但是数据库调用不是mock的好地方。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。