Groovy as your primary language

Groovy is fantastic. Remind we why I still program in Java?

I’ve been watching some Groovy videos from the recent SpringOne2GX conference. I’ve always really liked Groovy, and use it for all my personal projects. It’s so much more succinct, and the tools around it are very powerful.

After watching these videos, and seeing even more power available, as well as the fantastic enhancements around Type Checking and static compiling, I’m left asking myself why I code in Java at all.

Almost all valid Java code is valid Groovy code, so it’s easy to transition at your own pace. Groovy then allows you to remove so much ceremony, plus has so many powerful additions. AST transforms for creating an Immutable object. Defining a POJO while only having to define the properties. Powerful DSL’s that if written correctly, are Type checked at compile time, rather than at runtime.

Spock testing framework combines all the power of Junit, Mockito and JUnitParams in an even easier to read and use DSL for testing.

Even if you use Spring Boot, there is very good support for using Groovy everywhere. The main language, as the templating language (the new Groovy MarkupTemplate DSL is fantastic. Type checked at compile time rather than runtime, and optimizations performed by the compiler to improve performance at runtime).

Replacing Spring Data with GORM (from Grails). Spring Data allows for reflection based methods, BUT these aren’t checked until run time, and are limited in their functionality.

Using the latest GORM DSL, the queries are checked at compile time, and are much more flexible and readable. Instead of relying on a very long method name, a closure is used to define the request.

This will ensure the People object has a name property and an adult property at compile time.

DSL’s written correctly, are type checked at compile time, and your IDE can provide code assistance. Very powerful tool.

Watch the videos below and learn more about Groovy. I intend to incorporate it into my next project, and don’t want to code Java again.

Groovy after all these years at Mutual Life
Advanced Groovy Features
Modern approach to writing DSL

Spock – First Real Test (Edited)

For the project I’m working on right now, I decided to try Spock. Here’s my first specification (I’m still debating whether the data-driven approach is correct for this test, but this one example shows a number of the features of Spock quite concisely). All of the code (except for this test) is Java code.

The PageView object is the ‘fixture’. ICrawlerConfiguration is a bean that is injected into PageView. element is the object being passed to the isValidElement method.

Spock has its own built-in mocking/stubbing structure. The Mock being called here is part of the Specification object. By default, mocked objects will return the default for a given return value, so if you want the default return, no additional effort is required.

Also, for wiring, ICrawlerConfiguration is a private field on PageView WITH NO ACCESSORS defined. Because Spock is Groovy, the test can just set the value on PageView.

Similarly, isValidElement is a private method, and yet the test can call it. No more having to modify visibility of methods/fields just for testing.

The setup: code is defining the mocks. So, element.isDisplayed() >> true is stating that if isDisplayed is called on element, return true. Spock also supports verification of method calls, and returning varying values. [elink link=””]

All of the code in the where: is to provide data for the test. I think the format and usage is quite straightforward.

About the only thing I’ve noticed is it’s not necessarily obvious which line of data is being executed if a test fails. The output from Spock is quite detailed, but if you don’t have enough information in the expectation, it might be difficult to diagnose which specific row is causing issues.

EDIT: Look at the docs for the @Unroll annotation and using parameters in the method name. This addresses the issue of determining which line is in error. [elink link=””]

As far as adding Spock to an existing Maven/Java project, this was straightforward. Add a dependency to spock-core, and the gmaven plugin to the build block. As long as you end your test with Test, surefire will execute it as expected, and the results will be included in the usual manner. This also means that all test results will be collected with no additional requirements on the build server.

Definitely worth checking out. And here’s a great starting point [elink link=””]

Spock:A Groovy Testing Framework

I’ve been aware of Spock for sometime now. It uses Groovy for writing tests, and leverages a BDD approach (i.e. Given/When/Then). It has built-in mocking, easy data parameterization, and because it’s Groovy, succinct syntax.

It works well with the JUnit runner, so all IDE’s easily support it. Well worth investigating, and considering using on your next project. The Thucydides project is slowly converting old tests to Spock, and creating all new ones using it.

Using Spock old() method: [elink link=””]
Spock Docs: [elink link=””]