Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Making Java Groovy in Testing

 
Raymond Tong
Ranch Hand
Posts: 255
2
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?

Raymond
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34671
367
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raymond,
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
 
Raymond Tong
Ranch Hand
Posts: 255
2
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Raymond
 
Burk Hufnagel
Ranch Hand
Posts: 814
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raymond Tong wrote:Would you know if Spock with Eclipse do better?

Raymond,
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.

Burk
 
Kenneth A. Kousen
gunslinger & author
Ranch Hand
Posts: 100
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 http://groovy.codehaus.org/Using+MockFor+and+StubFor . 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: https://github.com/kousen/Making-Java-Groovy/blob/master/ch02/groovybaseball/src/test/groovy/service/GeocoderUnitSpec.groovy .

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 http://www.slideshare.net/kousen/spock-friendly-testing . I also did a presentation at DevNexus that is available at InfoQ: http://www.infoq.com/presentations/Spock .

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.
 
Burk Hufnagel
Ranch Hand
Posts: 814
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kenneth A. Kousen wrote:I also did a presentation at DevNexus that is available at InfoQ: http://www.infoq.com/presentations/Spock .


Ken,
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?

Thanks,
Burk
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic