合约测试是否有必要暗示存根？
最近，我读了很多关于合同和协作测试的文章(主要来自J.B. Rainsberger)。为了把它放进去，我开始了一个小项目。
根据我的理解，契约测试的责任是确保实现遵守其接口固有的契约。换句话说，它鼓励利斯科夫替代原则。
模仿一个对象合作者，基本上就是对它进行假设。现在，如果这些假设改变了，会发生什么？如果我这样模拟使用Mockito的合作者(这与存根的作用相同)：
when(collaborator.doSomething(someArgument)).thenReturn(someValue);当我修改collaborators接口(也就是它的契约)时，我不会注意到这些变化。
因此，我的问题是:当伪造协作者为被测系统提供间接输入时，应该使用存根来防止未被注意到的接口/契约更改，这是正确的吗？
下面是我已经检查过的一些链接：
removing-the-integration-test-scam-understanding-collaboration-and-contract
writing contract tests in java differently
我希望我说得足够清楚，如果不够清楚，我会尽我最大的努力让它变得更加透明。提前感谢你们所有人。
回答 2
Stack Overflow用户
发布于 2012-12-04 20:48:02
Stubs和Mock之间有明显的区别。
存根是一个替身，不能改变测试结果。例如，传递给主题的输入参数。
另一方面，mock可能会导致测试失败。它是测试对象间协作性的基础。如果未满足预期的协作，则测试将失败。
因此，在您的问题的上下文中，对系统的间接输入应该是存根。
Stack Overflow用户
发布于 2012-12-04 22:26:13
JB Rainsberger有一篇文章似乎准确地回答了你的问题：Who Tests The Contract Tests ?
所以这是我的问题:当伪造一个为被测系统提供间接输入的协作者时，应该使用存根来防止未被注意到的接口/契约更改，这是正确的吗？
使用存根，而不是什么？
模仿？这并没有太大的不同，正如@bryanbcook所指出的那样，存根在这种情况下更合适。
手动伪类，甚至没有实现与合作者相同的基类？好的。
IMO有两种合同变更：
- “硬”更改，即协作者方法的返回类型或参数类型的更改。这些修改很容易-它们不能被忽视，因为您的测试甚至不会再编译，只要您的假协作者实现了与真实collaborator.
- "Soft“更改相同的接口/基类，即协作者返回给定值或其他值的条件的更改，协作者可以返回或接受的值范围的更改，可以抛出的异常等。这些更难发现，但根据前面的文章，可以通过在约定测试和协作测试之间强制执行严格的对应关系来避免这些更改。
https://stackoverflow.com/questions/13692324
复制相似问题
腾讯云开发者
