最近，我阅读了很多关于合同和协作测试的文章（主要来自 JB Rainsberger）。为了融入其中，我开始了一个小项目。
据我了解，契约测试的职责是确保实现尊重其接口固有契约。换句话说，它鼓励了 Liskov 替换原则。
基本上，嘲笑对象合作者就是对它做出假设。现在，如果这些假设发生变化会发生什么？如果我像这样使用 Mockito 模拟协作者（这与存根相同）：
when(collaborator.doSomething(someArgument)).thenReturn(someValue);
当我修改协作者界面（即它的合同）时，我将无法注意到这些变化。
所以这是我的问题：当伪造一个为被测系统提供间接输入的合作者时，是否应该使用存根来防止未注意到的接口/合同更改？
以下是我已经检查过的一些链接：
我希望我足够清楚，如果没有，我会尽力使这更透明。提前感谢大家。
there is a clear separation between Stubs and Mocks.
A stub is a stand-in and cannot change the outcome of the test. For example, an input parameter that is passed into the subject.
A mock on the other hand can fail a test. It is the basis for the testing the collaboration between objects. If the expected collaboration is not met, the test should fail.
So in the context of your question, indirect inputs into a system should be stubs.
JB Rainsberger 的一篇文章似乎准确地回答了您的问题：谁来测试合同测试？
所以这是我的问题：当伪造一个为被测系统提供间接输入的合作者时，是否应该使用存根来防止未注意到的接口/合同更改？
使用存根而不是什么？
嘲笑？正如@bryanbcook 所指出的那样，这并没有太大的区别，无论如何，存根在这种情况下更合适。
甚至没有实现与合作者相同的基类的手动假类？当然。
IMO 有 2 种合同变更：
“硬”变化，即合作者方法的返回类型或参数类型的变化。这些修改很容易——它们不会被忽视，因为您的测试甚至不会再编译，只要您的假合作者实现与真正的合作者相同的接口/基类。
“软”变化，即协作者返回给定值或其他值的条件的变化，协作者可以返回或接受的值范围的变化，可能抛出的异常等。这些更难发现但是根据上述文章，可以通过强制合同测试和协作测试之间的严格对应来避免它们。