• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

Making Java Groovy in Testing

 
Ranch Hand
Posts: 258
2
IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
author & internet detective
Posts: 40793
828
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 258
2
IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 861
3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
gunslinger & author
Posts: 158
11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 861
3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic