File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Groovy and the fly likes Making Java Groovy in Testing Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Languages » Groovy
Bookmark "Making Java Groovy in Testing" Watch "Making Java Groovy in Testing" New topic

Making Java Groovy in Testing

Raymond Tong
Ranch Hand

Joined: Aug 15, 2010
Posts: 230

Hi Kenneth,

We tried to adapt Groovy from Java by start writing Groovy tests.
However, optional semi-colon, closure, syntax sugar collection rarely needed in testing code.
Moreover, it seems didn't integrate well with mocking framework (Mockito with Eclipse in our case).
i.e. code auto completion/static import not as good as Java with Eclipse

Would you know if Spock with Eclipse do better?

Jeanne Boyarsky
internet detective

Joined: May 26, 2003
Posts: 30123

Optional semicolons just save a tiny bit of time. They aren't a killer app for Groovy.

Why are you using Mockito in a groovy script though? Groovy has built in mocking

[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Raymond Tong
Ranch Hand

Joined: Aug 15, 2010
Posts: 230

Hi Jeanne,

From the page,
Unfortunately, Groovy's built-in mock support won't help us here. It doesn't allow us to test Java classes like this one as it relies on hooking into Groovy's object lifecycle mechanisms. Instead, we can use any of the available Java mocking packages

It seems the built in support could mock Groovy classes but not Java classes ??
Actually I was not aware Groovy has built-in mock support, would give it a try.

Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
Raymond Tong wrote:Would you know if Spock with Eclipse do better?

Personally, I like using Spock for testing because it helps me think about the expected behavior of the code being tested.
Another nice thing about writing tests in Groovy is that when an assert fails, it shows you exactly why:
Also note that with Spock there's less test code to write - note there's no assert statement - and you can do data driven test much easier than in Java.

I'd definitely recommend it - even if you go back to JUnit, you'll probably write better (clearer and more easily undertstod) tests.


SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
Kenneth A. Kousen
gunslinger & author
Ranch Hand

Joined: Sep 18, 2002
Posts: 89
I like writing JUnit tests in Groovy just for the code simplifications. Plus I can instantiate even Java classes with a map-based constructor, as in:

The cool part is that I can do that even for Java classes, as long as I'm writing my test in Groovy. Also, as Burk mentioned, the Groovy assert statement (technically known as a power assert) provides excellent debugging info for any assertion that fails. By the Groovy truth, assertTrue, assertNotNull, and assert all mean the same thing, too.

As for mocks, Groovy tests should be able to use Mockito the same way Java tests do. It's just a Java library, after all, so it should work cleanly. I admit I haven't tried that, though.

The mocking capability built into Groovy involves the MockFor and StubFor classes, which are part of the Groovy standard library. There's a web page discussing them at . The best part about those classes is that you can even mock locally instantiated variables (!) with them.

In my Groovy Baseball example in chapter 2, I have a geocoder that translates addresses to latitudes and longitudes. I have an integration test that demonstrates that the logic is working, but what if I'm not online? I use the StubFor method on the XmlSlurper to rig the parse method to return what I need, and this works even though the XmlSlurper is instantiated inside the fillInLatLng method. Honestly, I don't know of any other way to do that. If you want to see the code, it's in the GitHub repo for my book: .

Others mentioned the Spock framework, which has its own mocking capabilities built in. They're pretty powerful and clean, but again, you don't have to use them. If you want to see it, I have a set of slides about Spock available at . I also did a presentation at DevNexus that is available at InfoQ: .

One final note. Spock includes a JUnit runner, so if you write Spock tests you don't need to do anything different to run them. I frequently mix Spock tests and JUnit tests in the same project without a problem.

Kenneth A. Kousen, Ph.D. (assorted certs), President, Kousen IT, Inc.
Author of Making Java Groovy -
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
Kenneth A. Kousen wrote:I also did a presentation at DevNexus that is available at InfoQ: .

Thanks for mentioning DevNexus (a developer conference held each year in Atlanta, GA) - I hope you're planning on presenting there again.

When I first looked at Spock, it would generate an output (only from the command line, I think) that showed the method name, the given/when/the blocks with their descriptions, and the result, formatted so you could show it to a non-techie and they'd be able to tell what was going on. So if the spec looked like this:
The output looked something like this:I know there's been at least two attempts to improve this or make it available when running in Eclipse. Do you know if any were successful?

I agree. Here's the link:
subject: Making Java Groovy in Testing
Similar Threads
Concerns with Java+Groovy
Making Java Groovy - Integration Issues ?
Making Java Groovy: Test coverage for Groovy?
Groovy and TDD
Maven: Define different compiler for src/main and src/test code