unit-testing - 模拟比 stub 好吗？

Question

前段时间我读了Mocks Aren't Stubs Martin Fowler 的文章，我必须承认，在增加复杂性方面，我有点害怕外部依赖，所以我想问一下:

单元测试时使用的最佳方法是什么？

总是使用模拟框架来自动模拟被测试方法的依赖关系会更好，还是更喜欢使用更简单的机制，例如实例测试 stub ？

Answer 1

正如口头禅所说的那样，“去做最简单的事情，可能会奏效。”

如果假类(class)可以完成工作，那就去吧。

如果您需要一个具有多个模拟方法的接口(interface)，请使用模拟框架。

始终避免使用模拟，因为它们会使测试变得脆弱。您的测试现在对实现调用的方法有了复杂的了解，如果模拟接口(interface)或您的实现发生变化……您的测试会中断。这很糟糕，因为您将花费额外的时间让您的测试运行，而不仅仅是让您的 SUT 运行。测试不应不恰本地与实现密切相关。
所以用你最好的判断..我更喜欢模拟，因为它可以帮助我用 n>>3 方法更新一个假类。

更新 结语/审议:
(感谢 Toran Billups 以模拟测试为例。见下文)
嗨，Doug，好吧，我认为我们已经超越了另一场圣战 - Classic TDDers vs Mockist TDDers。我想我属于前者。

如果我在 test#101 Test_ExportProductList 上并且我发现我需要向 IProductService.GetProducts() 添加一个新参数。我这样做会使这个测试变绿。我使用重构工具来更新所有其他引用。现在我发现所有调用这个成员的 mockist 测试现在都崩溃了。然后我必须回去更新所有这些测试——浪费时间。为什么 ShouldPopulateProductsListOnViewLoadWhenPostBackIsFalse 失败？是因为密码坏了吗？而是测试被破坏了。我赞成一个测试失败 = 1 个修复位置。模拟频率与此相反。 stub 会更好吗？如果它我有一个 fake_class.GetProducts().. 肯定一个地方可以改变，而不是在多个期望调用中进行霰弹枪手术。最后，这是一个风格问题。如果您有一个通用的实用程序方法 MockHelper.SetupExpectForGetProducts() - 这也足够了.. 但您会发现这并不常见。

如果您在测试名称上放置白色 strip ，则测试很难阅读。模拟框架的大量管道代码隐藏了正在执行的实际测试。

要求您学习这种特殊风格的模拟框架