开发者

In Eclipse, how do I see the input to Assert.assertEquals when it fails?

开发者 https://www.devze.com 2022-12-18 03:57 出处:网络
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 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:

开发者_StackOverflow

In Eclipse, how do I see the input to Assert.assertEquals when it fails?

(source: yfrog.com)

.


  1. Comparison with failure trace is not a easy task when your object is a little bit complex.
  2. Comparison with debugger is useful if you have not redefined toString(). It remains still very tedious as solution because you should inspect with your eyes each objects from both sides.

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 :

In Eclipse, how do I see the input to Assert.assertEquals when it fails?


Problem is that it is avaiable only when you writeassertEquals() with String objects (in the screenshot, we can see that the option in the corner is not proposed with no String class) :

In Eclipse, how do I see the input to Assert.assertEquals when it fails?

You may use toString() on your object in assertion but it's not a good solution :

  • firstly, you correlate toString() with equals(Object)... modification of one must entail modification of the other.
  • secondly, the semantic is not any longer respected. 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 their toString() method.
It could offer a minimal visual way of comparing two unequals objects.
Of course, as equals(Object) is not necessarily correlated to toString(), 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.


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() will put the toString() representation of the expected and actual object in the message of the AssertionFailedError it throws, and eclipse will display that in the "failure trace" part of the JUnit view:

In Eclipse, how do I see the input to Assert.assertEquals when it fails?


(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()


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 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.


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消