It’s been a fruitful hour or so realising some things about how IntelliJ works and how the debugger behaves differently to running the code outright.
Lesson 1: The appearance (or lack) of <Click to see difference> in Junit results is not random. It only appears when you are comparing Strings in assertEquals – for objects, you get the traditional “expected <….> but was <….>”. So if your String methods are consistent with equals(), then you can put a .toString() in your assertEquals to get this to appear. Or, a better solution:
Lesson 2: You can copy the text between <…> in the junit output to the clipboard, then select the second set, right click and say “Compare with clipboard”. This gives you effectively the above without modifying your assertion questionably.
Lesson 3: The debugger changes the way your code executes, but only if you step through. Specifically, if toString() has side effects.
This one bears more explaining. My tests failed under Maven. My tests failed when run from IntelliJ. My tests failed when I run through the IntelliJ debugger without breaks. But as soon as I set a breakpoint and then continue execution, test succeeds. I’m trying to figure out why equals() is broken (its failing, but toString() produces identical results and displays all the elements), but stepping through is not going to help.
Why would it be different when stepping into the debugger? Because some of the variables were lazily initialised, and this was done in toString() via a call to a getter, but not equals() which was just using the variable reference. The debugger, when stepping, calls toString() on methods. This probably also highlights why its not a hot idea for toString() to have side effects 🙂
Things I should have known already, but weren’t immediately obvious at the time.