我一直在编写我的单元测试，大多数时候，我只是断言主题对象返回的输出值是单元测试的，偶尔我会使用验证调用来确保某些方法永远不会被调用或调用一定次数 .
现在，我被代码审查员要求在我正在使用的每个模拟器上添加验证调用，这除了我在输出上的断言之外 . 您认为，添加这些验证调用是否值得？
虽然这非常接近于纯粹的意见问题（因此也是StackOverflow的主题），但您使用的是mockito标签，因此我可以回答关于Mockito 's design philosophy as evidenced through blog posts from Mockito' s发起人Szczepan Faber与Mockito的类级别文档相关联的问题 .
在以下两种情况之一中添加 verify 次调用：
verify
它是进行或不进行调用的指定行为的一部分，就像在RPC层上的包装器一样 . 在这种情况下，外部交互是工作系统的与实现无关的要求，因此使用正确的参数检查正确的调用数是有意义的 .
没有其他用户可见的方法来确定对象的状态 . 您可以添加一些，但根据对象与环境的交互来推断状态可能会更具设计意义 .
您可能不需要在以下任何一种情况下添加 verify 调用：
至 verifyNoMoreInteractions 用于无关紧要或有明显副作用的来电（"Should I worry about the unexpected?" blog post来自Mockito documentation #8）
verifyNoMoreInteractions
验证使用非默认结果（Mockito documentation #2中的代码块"Asking and telling" blog link）存根的方法，因为如果存根方法提供必要的数据，测试应该只产生正确的结果 .
这里过度验证的风险是测试可能变得脆弱，使得完全合理的实现变化导致测试失败（即，调用或不调用不同的方法，或者不以相同的顺序调用） . 如果高级代码审核员告诉您添加验证，我不会说您不能：这绝对是一个判断调用，并且您的审核人员可能会考虑在实施方面采取额外防御措施 . 但是，请记住，测试的目的是验证实现是否符合promise，而不是实现在内部以某种方式查看或工作 . 如果您对验证过于苛刻，可能会导致以后的测试维护困难，同时让您无法接近工作代码 .
作为额外的资源，请参阅Martin Fowler's post "Mocks aren't Stubs"，其中描述了各种测试双打（假货，假人，存根，模拟）以及与经典状态测试一起使用或代替经典状态测试的一些权衡 .
1 回答
虽然这非常接近于纯粹的意见问题（因此也是StackOverflow的主题），但您使用的是mockito标签，因此我可以回答关于Mockito 's design philosophy as evidenced through blog posts from Mockito' s发起人Szczepan Faber与Mockito的类级别文档相关联的问题 .
在以下两种情况之一中添加
verify次调用：它是进行或不进行调用的指定行为的一部分，就像在RPC层上的包装器一样 . 在这种情况下，外部交互是工作系统的与实现无关的要求，因此使用正确的参数检查正确的调用数是有意义的 .
没有其他用户可见的方法来确定对象的状态 . 您可以添加一些，但根据对象与环境的交互来推断状态可能会更具设计意义 .
您可能不需要在以下任何一种情况下添加
verify调用：至
verifyNoMoreInteractions用于无关紧要或有明显副作用的来电（"Should I worry about the unexpected?" blog post来自Mockito documentation #8）验证使用非默认结果（Mockito documentation #2中的代码块"Asking and telling" blog link）存根的方法，因为如果存根方法提供必要的数据，测试应该只产生正确的结果 .
这里过度验证的风险是测试可能变得脆弱，使得完全合理的实现变化导致测试失败（即，调用或不调用不同的方法，或者不以相同的顺序调用） . 如果高级代码审核员告诉您添加验证，我不会说您不能：这绝对是一个判断调用，并且您的审核人员可能会考虑在实施方面采取额外防御措施 . 但是，请记住，测试的目的是验证实现是否符合promise，而不是实现在内部以某种方式查看或工作 . 如果您对验证过于苛刻，可能会导致以后的测试维护困难，同时让您无法接近工作代码 .
作为额外的资源，请参阅Martin Fowler's post "Mocks aren't Stubs"，其中描述了各种测试双打（假货，假人，存根，模拟）以及与经典状态测试一起使用或代替经典状态测试的一些权衡 .