This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of Java Interview Guide and have Anthony DePalma on-line!
See this thread for details.
The moose likes Testing and the fly likes Debugging Groovy Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Engineering » Testing
Bookmark "Debugging Groovy" Watch "Debugging Groovy" New topic

Debugging Groovy

Jeff Storey
Ranch Hand

Joined: Apr 07, 2007
Posts: 230
Hi Paul (and everyone else in the forum),
This may be more of a groovy forums question, but do you have any tips for debugging groovy code in an IDE (I use Eclipse)? Groovy adds so many layers of calls that it can be really tedious to step through the code, and it's a pain to put a breakpoint at every java line I'm interested in stopping at.


Jeff Storey
Software Developer
Jeanne Boyarsky
author & internet detective

Joined: May 26, 2003
Posts: 33132

Is it safe to assume you are using the Eclipse Groovy plugin?

[OCA 8 book] [Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Jeff Storey
Ranch Hand

Joined: Apr 07, 2007
Posts: 230
Yep! I wonder if they could have a debugging feature that skips the groovy code ... maybe I'll ping the developers on that one too, but I'm certainly open to other suggestions.
Paul Butcher
Ranch Hand

Joined: Nov 26, 2009
Posts: 41
Hey Jeff,

I'm afraid that I have no real experience of Groovy beyond knocking together a couple of quick toy scripts after reading a book on the subject. So I can't help you directly.

But having said that, remember that debugging is a great deal more than using a debugger. There are many alternative ways in which you can discover the information you need in order to debug your code - direct instrumentation, for example (which can be much more sophisticated than just scattering calls to System.out.println throughout the code!).

There's no doubt that your debugger is one of the most powerful tools in your toolbox, but as time goes on I find myself using it less and less. And it seems that I'm not alone - many other developers I talk to tell me that they're finding the same thing. So, what's going on?

What has changed is test-first development. Where in the past my first instinct might have been to break out the debugger, now it's to write a test. To understand why, it helps to think about why we might use a debugger. It's particularly helpful at three different points of the development life cycle:

  • During initial development, it's helpful when single-stepping through code helps to convince us that what it's really doing agrees with what we thought we were implementing.
  • If we have a theory about why the code is behaving in a particular way, we can use the debugger to confirm or refute this theory.
  • Finally, a debugger helps us explore code that is behaving in a way we simply don't understand.

  • But add test-first development into the equation, and the picture changes. Now, rather than stepping through the code to check that it behaves as we expect, we write one or more tests that demonstrate that it does. If we have a theory about what's causing a bug, we create a test that proves it. And the beauty of this is that unlike stepping though in a debugger, the results of which are ephemeral, a test is permanent. Not only does it prove that the code works now, but continues to do so in the future and can be run (and even improved) by other team members. Not only does it prove that our theory is correct, but we can subsequently use it to verify that our fix addresses the issue.

    So that leaves the debugger as an exploratory tool. It's a vital role to be sure, but it's a smaller one than it held a few years ago.


    Author of Debug It!: Find, Repair, and Prevent Bugs in Your Code
    Jeff Storey
    Ranch Hand

    Joined: Apr 07, 2007
    Posts: 230
    Hey Paul,

    I appreciate the insight. I actively practice TDD and I agree that it certainly reduces the amount I use the debugger, and that has really helped at the unit level. The place I find myself using the debugger more frequently is when I'm doing any manual integration and acceptance testing and something goes wrong. Also when I'm using 3rd party code (when I have the source), it's useful to be able to step through. Not to say that you can't do that with groovy code, but because of all the "magic" groovy does with the code, sometimes it's just a little more tedious and I find myself at times reverting to good old println (and in groovy, it's even easier since you don't need the whole System.out.println). Either way, I still find the benefits of groovy outweighing this issue.

    I agree. Here's the link:
    subject: Debugging Groovy
    It's not a secret anymore!