unit-testing - 必要的契约(Contract)测试是否意味着 stub ？

Question

最近，我阅读了很多关于契约和协作测试的文章(主要来自 J.B. Rainsberger)。为了让它融入其中，我开始了一个小项目。

根据我的理解，契约测试的职责是确保实现遵守其接口(interface)固有契约。换句话说，它鼓励了 Liskov 替换原则。

模拟对象协作器基本上就是对它进行假设。现在，如果这些假设发生变化会怎样？如果我像这样使用 Mockito 模拟协作者(这与 stub 相同):

 when(collaborator.doSomething(someArgument)).thenReturn(someValue);

当我修改协作者界面(即它的契约(Contract))时，我将无法注意到这些变化。

所以这是我的问题:当伪造一个向被测系统提供间接输入的协作者时，是否应该使用 stub 以防止未被注意到的接口(interface)/契约更改？

以下是我已经检查过的一些链接:

removing-the-integration-test-scam-understanding-collaboration-and-contract

writing contract tests in java differently

我希望我说得足够清楚，如果不够清楚，我会尽我所能使它更加透明。提前感谢大家。

Answer 1

stub 和模拟之间有明显的区别。

stub 是一个替代品，不能改变测试的结果。例如，传递给主题的输入参数。

另一方面，模拟可能无法通过测试。它是测试对象间协作的基础。如果没有达到预期的协作，测试应该失败。

因此，在您问题的上下文中，系统的间接输入应该是 stub 。