- 关于在测试方法之后放置重置
我认为最好在测试方法之后重新设置模拟，因为这意味着确实存在测试期间发生的某些事情需要清除。
如果重置是在测试方法之前完成的，我不确定应该在重置测试之前发生了什么情况？非嘲笑对象呢？是否有原因（也许有）？如果有原因在代码中没有提到它（例如方法名）？等等。
不喜欢基于Spring的测试
- 背景
使用Spring就像放弃对一个类的单元测试; 使用Spring时，您对测试的控制较少： 隔离 ， 实例化 ， 生命周期
，可以在单元测试中引用一些looked属性。但是，在许多情况下，Spring提供的库和框架不是那么“ 透明
”，为了进行测试，您可以更好地测试整个组件的实际行为，例如使用Spring MVC，Spring Batch等。
设计这些测试要麻烦得多，因为在许多情况下，这迫使开发人员设计 集成测试
以认真测试生产代码的行为。由于许多开发人员并不了解有关代码在Spring中如何生活的所有细节，因此尝试使用单元测试来测试类可能会引起很多意外。
但是麻烦仍然存在，测试应该快而小，以向开发人员提供 快速反馈
（例如Infinitest之类的IDE插件非常有用），但是使用Spring进行的测试本质上更慢并且消耗更多的内存。这样一来，它们运行的频率就会降低，甚至完全避免在本地工作站上运行它们，以便以后在CI服务器上发现它们发生故障。
2. Mockito和Spring的生命周期
因此，当为子系统设计 集成测试 时，您最终会得到很多对象，并且显然还有协作者，这些对象可能被嘲笑了。生命周期由Spring
Runner控制，但Mockito模拟不是。因此，您必须自己管理模拟生命周期。
关于Spring
Batch项目期间的生命周期，我们再次遇到了一些对非模拟的残留影响的问题，因此我们有两种选择，每个测试类只能使用一种测试方法，或者使用肮脏的上下文技巧：
@DirtiesContext(classMode=ClassMode.AFTER_EACH_TEST_METHOD)。这导致测试速度变慢，内存消耗增加，但这是我们的最佳选择。使用此技巧，您不必重置Mockito模拟。
- 黑暗中可能的光
我对该项目不太了解，但是springockito可以为您提供有关生命周期的一些帮助。该注释子项目似乎更好：它似乎让Spring管理bean的生命周期在Spring容器中，并让测试控制是如何被使用嘲弄。我仍然没有使用此工具的经验，因此可能会有惊喜。
作为免责声明，我非常喜欢Spring，它提供了许多出色的工具来简化其他框架的使用，可以提高生产力，可以帮助设计，但是就像人类发明的每一种工具一样，总会有一个粗糙的边缘（如果不是更多的话…
）。
附带说明一下，有趣的是，这个问题恰好发生在 JUnit 上下文中，因为JUnit实例化每个测试方法的测试类。如果测试是基于 TestNG的，
则该方法可能会有所不同，因为TestNG仅创建测试类的一个实例，无论使用Spring还是什么，其余的模拟字段都是必选的。
旧答案：
我不喜欢在spring的conxtext中使用Mockito模拟。但您是否正在寻找类似的东西：
@After public void reset_mocks() { Mockito.reset(placeOrderService);}
