This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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.
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.
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.