JMock断言在TearDown中是否满足？
我不知道为什么，但我总是这样编写 JMock 测试：
@Test
public void testMyThing() throws Exception {
mockery.checking(new Expectations() {{
oneOf(mockObj).foo();
}});
testObj.bar(); // calls mockObj.foo()
mockery.assertIsSatisfied();
}
但是当有很多测试时，将 assertIsSatisfied 移到拆解会更好吗？
@After
public void tearDown() throws Exception {
mockery.assertIsSatisfied();
}
I don't know why, but I have always written my JMock tests like this:
@Test
public void testMyThing() throws Exception {
mockery.checking(new Expectations() {{
oneOf(mockObj).foo();
}});
testObj.bar(); // calls mockObj.foo()
mockery.assertIsSatisfied();
}
But when there are many tests, is it better to move assertIsSatisfied to the tear-down?
@After
public void tearDown() throws Exception {
mockery.assertIsSatisfied();
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
推荐的方法是使用 JMock 运行程序。使用注释该类，
这将在测试生命周期中的正确位置调用断言。拆卸不是正确的位置，因为可能无法正确报告故障，并且可能会扰乱其他清理工作。
我们在存储库中还有一个与新的 @Rule 基础设施配合使用的嘲笑规则。
The recommended way to do this is to use the JMock runner. Annotate the class with
This will call the assertion at the right place in the test lifecycle. Teardown isn't the right place as a failure might not be reported in correctly and might mess up other cleanup.
We also have a mockery rule in the repository that works with the new @Rule infrastructure.
是的，我倾向于在拆解中进行。通过将样板文件移至 @After 中，它将各个测试方法的重点放在实际测试的内容上 - 对我而言，测试尽可能具有表现力和可读性至关重要。
事实上，我有时会更进一步，使用
JMockSupport基类来为我处理Mockery（以及提供mock( 的便捷实现） ...））。当然，这只是一种方便，绝不是像 JUnit 3 中那样的要求。Yes, I tend to do it in teardown. It keeps the focus of the individual test methods on what they're actually testing, by removing the boilerplate out into the
@After- it's critical to me that tests are as expressive and readable as possible.In fact, I sometimes take it further than that, and use a
JMockSupportbase class that handles theMockeryfor me (as well as providing convenience implementations ofmock(...)). This is just a convenience, of course, and by no means a requirement like it was in JUnit 3.