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
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 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)
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 .
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.
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?