• 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

Debugging Groovy

 
Ranch Hand
Posts: 230
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

thanks,
Jeff
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jeff,
Is it safe to assume you are using the Eclipse Groovy plugin?
 
Jeff Storey
Ranch Hand
Posts: 230
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
     
    Jeff Storey
    Ranch Hand
    Posts: 230
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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.

    Thanks,
    Jeff
     
    reply
      Bookmark Topic Watch Topic
    • New Topic