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

Groovy for Android Development

Apple recently announced the new programming language for iOS called Swift. One of the languages mentioned by Apple as providing inspiration was Groovy.

Here’s a presentation showing how to use Groovy for Android development. Looks a lot nicer than using Java for it. Take a look and see what you think. I’ll be investigating this for any Android development I have to do.

[elink link=””]

Groovy Continues to Evolve

I’ve been intrigued by Groovy, and the whole community ever since attending SpringOne2GX in 2009. I’ve written a few things using Groovy, Spock, Geb and use Gradle for all my personal projects.

Here are two recent presentations showing off new features of Groovy, and the features added to make Groovy very good for creating DSLs.

The DSL video is a bit long, but quite informative. They cover some simple things early on, so if you’re familiar with Groovy, skip to the last 1/2. They discuss providing additional information in the DSL’s jar file to aid both Eclipse and Intellij so they can provide code assist on your DSL. You can restrict the functions, methods, classes, imports etc that can be accessed in the DSL (as otherwise, it’s just running Groovy code, so someone could do System.exit(0) in their DSL, and cause havoc.

Groovy itself has a number of additional items for providing type checking, and static compilation. I tend to write Groovy similar to Scala in the sense of defining the parameter types of methods.

Personally, I’d stop writing Java and start writing Groovy or Scala today. I’m tired of waiting for Java to get the features, power and lack of verbosity of the alternative languages.

  • Lift-off with Groovy 2.1 : [elink link=””]
  • Advanced Groovy Tips and Tricks : [elink link=””]
  • Creating Groovy DSLs : [elink link=””]

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=””]