Kirk Pepperdine: Do you see any other common patterns and common project types that can benefit from Groovy? König: Yes. Whenever you need some interactive behavior, interactive dynamic behavior in your application like you want to have a key hole for administrative purposes, or a key hole in your Java application for digging into the internals for support reasons for example, whenever we do support for our Java application for the Groovy enabled, we just go on the customer side and we can look into the internals and into the JVM, into the objects, passing any kind of message to them and find out what's going on inside. And this has proven to be so valuable that we use Groovy for all customer-related support issues. ... Pepperdine: And Groovy is really a tool that you can use to augment your unit testing? König: Yes, you can do that as well. Some people say that they use Groovy for unit testing Java code. This is what you can do. My personal feeling is that you should write the unit test in the same language that you expect your class on the test to be used from. Pepperdine: How come? König: As soon as you have a Java class and you expect it to be used from Java, you want to have the feedback from the test on how it feels to use that class. If you have a Groovy class and you expect it to be used from Groovy, you should write your unit test in Groovy because it gives you feedback on how it feels to use that class from Groovy. This is when you're using unit testing not as a validation technique but as a design technique, as a first feedback whether you have designed your system correctly.Read the Q&A with Dierk König
Kirk Pepperdine, TSS's roaming contributor recently spoke with Canoo's Dierk König about the Canoo webtest tool, Groovy, and how they all fit together in development and test environments. From the interview:
- Posted by: Nate Borg
- Posted on: January 31 2008 16:29 EST
I've been using Groovy for close to a year now on a new project I've been working on. I was given the directive that I could do the UI in Groovy but the core logic had to be in Java. So I wrote the domain model and integration tier in Java, and wrote the Swing app using Groovy's SwingBuilder. I agree with the idea that you should write your unit tests in the language you will expect your class to be used from. In my case, that would be Groovy, so I wrote all my unit tests in Groovy. Groovy truly is the best thing that has come along in a LONG time. All the power, expressiveness, and flexibility of a dynamic language, without losing anything from Java. I had tried JRuby, but the Java integration was less than stellar (May be different now, but this was close to a year ago when I tried it) The only things that annoy me slightly, are the cryptic stack traces when crashing within a swing event closure, and loss of good IDE support in Eclipse. Those things are minor however, when I consider my code is so much more readable, and I estimate SwingBuilder code is about 1/3 the size of plain Swing. Thanks, guys, and keep up the great job with Groovy!
König: That's complimentary, let's say…Pepperdine: Complimentary.No comprendo! What compliment are they talking about? Or did they mean complEmentary??