IntelliJ Tips Discovered after Weirdness in the Debugger

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.

Advertisements

One response to “IntelliJ Tips Discovered after Weirdness in the Debugger

  1. I’m not going to laugh; its funny, but painful.

    I’ve actually used unexpected side effects to abuse code (specifically a bit in axis), by setting a breakpoint on a line, and telling Idea not to break, but to evaluate an expression. You can put any method in there, even something that returns void, so you can use it to insert stuff into running code.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s