在编写单元测试时，对于与单元交互的每个对象，我都采取了以下步骤（从我对 JBrains 的Integration Tests are a Scam 的理解中窃取）：
当我决定重构一个在步骤 2 中模拟了响应的对象时，我的问题就出现了。如果我更改对象响应调用的方式，那么其他对象对该调用的所有测试都不会失败，因为它们有都被嘲笑以匹配旧风格。您如何使模拟与他们正在模拟的对象保持同步？对此有最佳做法吗？还是我完全误解了一些事情并且做错了？
【问题讨论】：
标签： unit-testing tdd
我是这样做的。
假设我必须更改接口方法foo() 的响应。我将存根foo() 的所有协作测试收集在一个列表中。我收集方法 foo() 的所有契约测试，或者如果我没有契约测试，我将 foo() 的所有当前实现的所有测试收集在一个列表中。
现在我创建一个版本控制分支，因为它会乱一会。
我 @Ignore（JUnit 发言）或以其他方式禁用存根 foo() 的协作测试并开始一一重新实现和重新运行它们。我让他们都过去了。我可以做到这一点，而无需触及 foo() 的任何生产实现。
现在我一一重新实现实现foo() 的对象，其预期结果与存根的新返回值相匹配。请记住：协作测试中的存根对应于合同测试中的预期结果。
此时，所有协作测试现在都假定来自foo() 的新响应，而合同测试/实施测试现在期待来自foo() 的新响应，所以它应该都可以正常工作。(TM)
现在整合你的分支，给自己倒点酒。
【讨论】：
修订： 这是一个权衡。通过将对象与环境隔离开来轻松测试 vs 确信所有部分组合在一起时一切正常。
【讨论】：
首先，通过集成测试获得这种覆盖率肯定更难，所以我认为单元测试仍然更胜一筹。不过，我觉得你说的有道理。很难让对象的行为保持同步。
对此的答案是进行部分集成测试，这些测试具有 1 级深度的真实服务，但除此之外是模拟。例如：
var sut = new SubjectUnderTest(new Service1(Mock.Of<Service1A>(), ...), ...);
这解决了保持行为同步的问题，但增加了复杂性，因为您现在必须设置更多的模拟。
您可以使用可区分联合在函数式编程语言中解决此问题。例如：
// discriminated union
type ResponseType
| Success
| Fail of string // takes an argument of type string
// a function
let saveObject x =
if x = "" then
Fail "argument was empty"
else
// do something
Success
let result = saveObject arg
// handle response types
match result with
| Success -> printf "success"
| Fail msg -> printf "Failure: %s" msg
您定义了一个名为ResponseType 的可区分联合，它有许多可能的状态，其中一些可以接受参数和其他元数据。每次访问返回值时，都必须处理可能的各种条件。如果您要添加另一个失败类型或成功类型，编译器会在您每次不处理新成员时向您发出警告。
这个概念对处理程序的演变大有帮助。 C#、Java、Ruby 和其他语言使用异常来传达故障情况。但是这些故障情况通常根本不是“异常”情况，最终导致您正在处理的情况。
我认为函数式语言最接近为您的问题提供最佳答案。坦率地说，我不认为有一个完美的答案，甚至在许多语言中都没有一个好的答案。但是编译时检查可以走很长的路
【讨论】：
您不应该相信人类（甚至您自己）会保持模拟和真实软件组件的同步。
我听到你问了？
那你的建议是什么？
我的建议是；
你应该写模拟。
您应该只为您维护的软件组件编写模拟。
如果您与其他开发人员一起维护软件组件，您和其他开发人员应该一起维护该组件的模拟。
你不应该模拟别人的组件。
当您为组件编写单元测试时，您应该为该组件的模拟编写单独的单元测试。我们称之为 MockSynchTest。
在 MockSynchTest 中，您应该将模拟的每个行为与真实组件进行比较。
当您对组件进行更改时，您应该运行 MockSynchTest 以查看您的模拟和组件是否不同步。
如果您需要在测试组件时不维护的组件的模拟，请询问该组件的开发人员有关模拟的信息。如果她能给你提供一个经过良好测试的模拟，对她有好处，对你来说很幸运。如果她不能，请让她遵循本指南并为您提供经过良好测试的模拟。
这样，如果你不小心让你的模拟不同步，那里会有一个失败的测试用例来警告你。
这样你就不需要知道mock的外部组件的实现细节了。
【讨论】：