Kirk Pepperdine, TSS's roaming contributor recently spoken with Canoo's Dierk König about the Canoo webtest tool, Groovy, and how it all fits together in development and test environments.

Kirk Pepperdine: I'm sitting here at the Grails eXchange conference with Dierk König. Dierk, could you introduce yourself and tell us a little bit about what you do?

Dierk König: Right. I'm Dierk König, I'm working for Canoo Engineering in Basel, Switzerland. I am myself located in Zurich, but most of our customers are the big banks and the national institutes that we deliver professional services to and products mostly around testing and unit testing activities. So quality assurance is one of our big issues that we are concerned with.

Pepperdine: You're finding the QA teams now are using Groovy to write tests. How is Groovy being used in a test environment?

König: You can use Groovy for writing functional tests against the application. At this time, mostly against web applications, where you can use for example Canoo WebTest and write your scripts either in Ant file format or as Groovy scripts.

Pepperdine: So WebTest is a tool that you've written then?

König: Yes, WebTest is an open source tool.

Pepperdine: Open, so you've opened sourced this particular tool.

König: Yes.

Pepperdine: And is it something like JUnit test or HTTP Unit Test?

König: It tests from a functional perspective, so imagine you would have a test script that you give to a manual tester, say go to this URL, click on this link, verify this and that text appears at this and that position in your web application, and you're defining, you're specifying the workflow through your application with the expected workflow and unexpected things that you want guaranteed not to happen like throwing up java.lang.NullPointerException on the interface for example and it's not what you sometimes see and you can run your test automatically like hundreds of thousands of tests against the application, and the main benefit is that you can have countless tests in a repeatable way and test against all the regressions that you're going to possibly have in your web application.

Pepperdine: So is this similar to the style of Apache JMeter? I know Apache JMeter is a load testing tool so it doesn't specifically do functional testing but in terms of how you set the scripts up and to work…

König: That's complimentary, let's say…

Pepperdine: Complimentary.

König: If you have specified your expected workflow, with WebTest, you can use it with JMeter to test the load of these specialized workflows.

Pepperdine: Right. So, how does this tie in with Groovy then? You've written web testing in Groovy or you can script the test in Groovy, or…?

König: Yes, you can write your expectations against the web application either in Ant XML format or you can use it in Groovy format as Groovy scripts. And this is actually what Grails is doing when you run the Grails application you can have your web test generated and this will then be a Groovy style WebTest.

Pepperdine: So the tool accepts either Groovy or XML with the sharp pointy things.

König: Exactly.

Pepperdine: So, the obvious benefit of Groovy in my mind is that I'm not going to get caught up by the sharp pointy things.

König: Yes.

Pepperdine: Do you see that as being an advantage to using Groovy in a testing environment?

König: Yes, exactly. It reads like the main specific language at that point, although there's not anything specific to WebTest when running this because it's just plain AntBuilder stuff and that's something the Groovy programmers know already, but it reads very nicely, it reads click, link, label, show or something. That means, “click on the link that's labeled with show.” So it's hard to be any more concise than this kind of expression.

Pepperdine: And the link can move around as long as it's labeled, you can find it and test it.

König: Yes. And this is one of the main advantages of WebTest that if you have various means of expressing very exactly the link to click on, if there's only one click on, one link on the page that's labeled with show, it will find it. But if there're multiple links with the same label you can go with expert expressions to find it.

Pepperdine: In this case you decided to use Groovy, you could have decided to use straight Java or some other type of language. What were the benefits in Groovy that led you to this choice and what were the benefits you've seen in Groovy over some other language choices that you might have had?

König: It's mostly two things. And one thing is it's just so expressive, you can write one line after the other click link verify text, click button, set input field, and it reads like prose, a text. So expressiveness is one thing, and the second thing is we hardly have to do anything, because everything is programmed as Ant tasks and having this, having Ant tasks being executed as Groovy files, you don't have to do anything for that, you just use AntBuilder and you're there. So there was no implementation effort whatsoever to make this happen.

Pepperdine: So, this is an obvious case where a particular project can really benefit from the use of Groovy.

König: Yes, very much.

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 administrational 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 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: Just to go in and inspect the current state of your executing application.

König: Exactly.

Pepperdine: And that's a visibility that really is not so easily obtained in a regular Java application, is it?

König: You just cannot in regular Java. This is what I call in vivo inspection. You know you don't have to put the patient under narcosis to inspect him. You know, you're inspecting the live object.

Pepperdine: Right. And there's nothing that tells the truth better than the live object.

König: Exactly.

Pepperdine: How difficult is it to teach people to use Groovy? I mean you have people that are not exposed to Groovy, you have QA testers, software people who may not be exposed to a lot of different languages to begin with. Is it difficult for them to actually learn the language? How much of it do they have to learn it in order to be functional in this environment?

König: When talking about the QA people which are non-programmers, or non technical people, they usually don't even care about whether this is a programming language or not. They just have a way of expressing the expected behavior of the application which you tell them whatever you write click link, you will click on the link. This is what they understand and they're not exposed to any kind of conditional logicor looping or inheritance or whatsoever, they just have plain single sequence of lines.

Pepperdine: So they're not really learning Groovy then, are they? They are learning your DSL that you've written on top of it.

König: Exactly.

Pepperdine: When they start getting into like click link, link, that, a little later on they say, oh yeah, I'd like to do something like a little bit more that's maybe not supported by this.

König: Yeah.

Pepperdine: Do you find that it gives some confidence to try to go in and change this particular system or do they find difficulties doing that afterwards?

König: Changing any existing test like this is particularly easy. It's more complicated if you start from scratch and there's nothing that you can adapt to. Changing is very easy. And because the initial steps are harder to achieve in the beginning, if you give them a jump start and generate the core of the test for them and generate and example test that they can run, this is what Grails is doing actually, when you have a newly created Grails application, you can create the initial tests that they then can use and adapt to their needs.

Pepperdine: So they really don't need to know anything about Groovy then, they'll just start being functional. So you're actually not teaching the QA engineers any Groovy.

König: No. I don't teach any Groovy to QA engineers. I do teach Groovy to Java engineers, which is a second part of the story. There are, I don't know, how many million Java programmers on this planet, some say three million, others say nine million. For a typical Java programmer it's very easy to pick up Groovy. It can look identical to Java, and you can gradually go into the more dynamic style of Groovy and adapt new patterns and so on, so it's really easy to teach Java programmers Groovy.

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.

Pepperdine: So when you're following a testing development methodology, you're suggesting that all my Java code be unit tested with Java classes, because the TDD in that case is really helping to drive the design, no?

König: This is subtly wrong. If I write Java code that I expect to be called from Groovy, then I would write the unit test in Groovy.

Pepperdine: Right. So that's consistent then.

König: Yeah. The goal is to write the unit test in the same language that I expect my class and the test to be called from.

Pepperdine: Do you find that it really makes that big of a difference?

König: It gives you the correct feedback from tests. The test is the first user of your system. And it should give you the feedback whether the system can be used like you intended it to be used.

Pepperdine: So you don't really use Groovy to replace the existing unit tests in Java. You don't find it advantageous then to write all these tests, just specifically in Groovy following this particular principle then.

König: No, I wouldn't do so.

Pepperdine: You wouldn't do so. You know, I guess then you don't do that in practice.

König: No, I don't.

Pepperdine: Ok. Is there any other recommendation that you can make?

König: I would say whenever somebody is looking for dynamic behavior on the JVM or looking for easy DSLs on the JVM then Groovy is a very good candidate to look at.

Pepperdine: Thank you very much.

König: Thank you.

Biography

Kirk Pepperdine is the Chief Technical Officer at JavaPerformanceTuning.com and has been focused on Object technologies and performance tuning for the last 15 years. He is also a contributing editor for TheServerSide.com.

PRINTER FRIENDLY VERSION