在 Eclipse 中,当 Assert.assertEquals 失败时,如何查看它的输入?
我不是 Eclipse 专家,所以请原谅我的笨拙。
在 Eclipse 中,当我调用 Assert.assertEquals(obj1,obj2) 但失败时,如何让 IDE 显示 obj1 和 obj2?
我正在使用 JExample,但我想这应该没有什么区别。
编辑:这是我所看到的:
(来源:yfrog.com)
。
I'm not much of an Eclipse guru, so please forgive my clumsiness.
In Eclipse, when I call Assert.assertEquals(obj1,obj2) and that fails, how do I get the IDE to show me obj1 and obj2?
I'm using JExample, but I guess that shouldn't make a difference.
Edit: Here's what I see:
(source: yfrog.com)
.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
Junit Eclipse 插件在出现故障时提供了一个选项:“将实际结果与预期测试结果进行比较”。该视图与经典内容比较工具足够接近:
问题是,只有当您使用
String
对象编写assertEquals()
时,它才可用(在屏幕截图中,我们可以看到角落里的选项没有建议没有 <代码>字符串类):您可以在断言中对对象使用
toString()
但这不是一个好的解决方案:toString()
与 < code>equals(Object)...对一个的修改必须对另一个进行修改。toString()
应该返回一个有用的方法来调试一个对象的状态,而不是识别 Java 语义中的对象 (equals(Object)
)。据我所知,我认为 JUnit Eclipse 插件缺少一个功能。
当比较失败时,即使我们比较的不是
String
对象,它也应该提供依赖于toString()
方法的两个对象的比较。它可以提供一种比较两个不相等对象的最小视觉方式。
当然,由于
equals(Object)
不一定与toString()
相关,突出显示的差异应该用我们的眼睛来研究,但无论如何它已经是一个很好的基础了,比没有比较工具要好得多。Junit Eclipse plugin offers a option when there is a failure : "Compare actual With Expected TestResult". The view is close enough to classic content comparison tools :
Problem is that it is avaiable only when you write
assertEquals()
withString
objects (in the screenshot, we can see that the option in the corner is not proposed with noString
class) :You may use
toString()
on your object in assertion but it's not a good solution :toString()
withequals(Object)
... modification of one must entail modification of the other.toString()
should return a useful method to debug the state of one object, not to identify an object in the Java semantic (equals(Object)
).According to me, I think that the JUnit Eclipse plugin misses a feature.
When comparison fails, even when we compare not
String
objects, it should offer a comparison of the two objects which rely on theirtoString()
method.It could offer a minimal visual way of comparing two unequals objects.
Of course, as
equals(Object)
is not necessarily correlated totoString()
, highlighted differences should be studied with our eyes but it would be already a very good basis and anyway, it is much better than no comparison tool.如果 JUnit 视图中的信息对您来说不够,您可以随时设置异常断点,例如 java.lang.AssertionError。运行测试时,调试器将在实际抛出异常之前立即停止。
If the information in the JUnit view is not enough for you, you can always set a exception breakpoint on, for example, java.lang.AssertionError. When running the test, the debugger will stop immediately before the exception is actually being thrown.
Assert.assertEquals()
会将预期对象和实际对象的toString()
表示形式放入它抛出的AssertionFailedError
消息中,并且 eclipse将在 JUnit 视图的“失败跟踪”部分显示:(来源:ibm.com)
如果您想要检查复杂的对象,则必须使用调试器并在
Assert.assertEquals()
中放置一个断点Assert.assertEquals()
will put thetoString()
representation of the expected and actual object in the message of theAssertionFailedError
it throws, and eclipse will display that in the "failure trace" part of the JUnit view:(source: ibm.com)
If you have complex objects you want to inspect, you'll have to use the debugger and put a breakpoint inside
Assert.assertEquals()
你看到什么了?
当你执行assertTrue()并且失败时,你会看到一个null。
但是当你执行assertEquals时,它应该向你展示它的预期和实际得到的结果。
如果您正在使用 JUnit,请确保您正在查看 JUnit 视图并将鼠标移至失败的测试。
What are you seeing?
When you do assertTrue() and it fails, you see a null.
But when you do assertEquals, it is supposed to show you what it expected and what it actually got.
If you are using JUnit, mke sure you are looking at the JUnit view and moving the mouse to the failed test.
即使您比较的对象不是字符串,FEST Assert 也会在断言失败时显示比较对话框。我在我的博客上更详细地解释了它。
FEST Assert will display comparison dialog in case of assertion failure even when objects you compare are not strings. I explained it in more detail on my blog.
如果您要比较的是字符串,那么您可以双击堆栈元素,它将弹出一个对话框,显示 Eclipse 中的差异。
但这仅适用于字符串。对于一般情况,查看真正原因的唯一方法是安装断点并单步执行。
If what you are comparing is a String then you can double click stack element and it will popup a dialog showing the diff in eclipse.
This only works with Strings though. For the general case the only way to see the real reason is to install a breakpoint and step into it.