• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

assertEquals is wrong?

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

I find it hard to believe that assertEquals is wrong but I can't for the life of me tell the difference between these two outputs:

Expected:


Actual:


Trace:


In the compare window, no red is shown. I pasted actual and expected into separate textfiles, compared the difference with Eclipse and nothing was found. Other tests that compare output are passing, it is just this one. Help please?
 
Sheriff
Posts: 3063
12
Mac IntelliJ IDE Python VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The trace is showing you what was expected and what was actual, and it looks like the expected string has an extra linefeed in it. Both contain square brackets [] that I don't see in your sample outputs.
 
Luke Winter
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Greg Charles wrote:The trace is showing you what was expected and what was actual, and it looks like the expected string has an extra linefeed in it. Both contain square brackets [] that I don't see in your sample outputs.



Thank-you for your reply Greg. I see that it is the case that the expected looks as if it requires another line, but looking at the expected string:



where LS is the System line separator, it does not require an additional line.

EDIT: even if I copy the actual output into the expected output, I still get a mismatch.
 
Greg Charles
Sheriff
Posts: 3063
12
Mac IntelliJ IDE Python VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, you could get the source code for whatever version of JUnit you're using, and step into it with a debugger to see what's going on. The source I'm looking at doesn't add square brackets, or even those triangular brackets. It also doesn't truncate the string and add an ellipsis as far as I can tell, so I don't think you're feeding it the strings you think you're feeding it.
 
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You could also try do a actual.equals(expected) yourself within the JUnit code to see what that returns. Then you'll know if it's something with the assertEquals that's causing this problem or if those 2 strings aren't really equal.
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Luke Winter wrote:I find it hard to believe that assertEquals is wrong but I can't for the life of me tell the difference between these two outputs:
...
In the compare window, no red is shown. I pasted actual and expected into separate textfiles, compared the difference with Eclipse and nothing was found. Other tests that compare output are passing, it is just this one. Help please?


Have you thought about putting your directions in a Direction enum?

To be honest, I'm not quite sure what all these String comparisons are doing - the Strings themselves appear to be some sort of indicator of direction, but I'm still not sure exactly how. If you put them in an enum, you could add an asString() method (or override toString()) that returns the display String for a particular Direction.

Better still, you could then compare Directions rather than Strings.

Winston
reply
    Bookmark Topic Watch Topic
  • New Topic