[Java] 何时使用Mockito.verify()?


Answers

大卫的答案当然是正确的,但并不能解释你为什么要这样做。

基本上,当单元测试你正在孤立地测试一个功能单元时。 您测试输入是否产生预期的输出。 有时候,你也必须测试副作用。 简而言之,验证允许你这样做。

例如,您有一点应该使用DAO存储事物的业务逻辑。 您可以使用集成测试来实现此目的,该测试将DAO实例化,将其挂接到业务逻辑,然后在数据库中四处查看以查看是否存储了预期的内容。 这不再是单元测试。

或者,您可以嘲笑DAO并验证它是否按照您期望的方式被调用。 使用mockito,您可以验证是否调用了某些东西,调用它的频率,甚至在参数上使用匹配器以确保以特定方式调用它们。

像这样的单元测试的另一面确实是你将测试绑定到实施上,使得重构变得更加困难。 另一方面,良好的设计气味是正确运用它所需的代码量。 如果你的测试需要很长时间,那么设计可能有些问题。 因此,需要测试的很多副作用/复杂交互代码可能不是一件好事。

Question

我为三个目的编写jUnit测试用例:

  1. 为了确保我的代码在全部(或大部分)输入组合/值下满足所有必需的功能。
  2. 为了确保我可以更改实现,并依靠JUnit测试用例告诉我,我的所有功能仍然满足。
  3. 作为我的代码处理所有用例的文档,并充当重构的规范 - 如果代码需要重写。 (重构代码,如果我的jUnit测试失败 - 你可能错过了一些用例)。

我不明白为什么或什么时候应该使用Mockito.verify() 。 当我看到verify()被调用时,它告诉我,我的jUnit正在意识到实现。 (因此,改变我的实现会打破我的jUnits,即使我的功能不受影响)。

我在找:

  1. 适当使用Mockito.verify()的准则应该是什么?

  2. jUnits是否意识到或紧密结合被测试类的实现从根本上说是正确的?




我必须说,从古典方法的角度来看,你是完全正确的:

  • 如果您首先创建(或更改)应用程序的业务逻辑 ,然后采用(采用)测试Test-Last方法 )来覆盖它 ,那么让测试知道有关软件的工作方式是非常痛苦和危险的,检查输入和输出。
  • 如果您正在实践一种测试驱动的方法 ,那么您的测试将首先被编写,需要改变并反映软件功能的用例实施取决于测试。 这有时候意味着你希望你的软件以某种特定的方式实现,例如依赖于其他组件的方法,甚至称它为特定的时间。 这就是Mockito.verify()派上用场的地方!

重要的是要记住,没有通用工具。 软件类型,规模,公司目标和市场情况,团队技能以及其他许多因素都会影响您决定在特定情况下使用哪种方法。