We're looking into improving our testing process for some of our applications, and the idea that's been put forward it to write unit tests in Groovy and automatically run them with Maven.

The first application to get this treatment is written in Java, but I've been told that some of the classes being tested need to be renamed as ".groovy" files * and they will then be compiled as Groovy classes, not as Java classes. This renaming can all be done using Maven and Ant, but I'm concerned that if we compile our classes as Groovy classes, we're not actually testing them as Java classes, which is how they will be deployed.

During the demo, it was also shown that Groovy does not compile to the same bytecode that Java does. There was at least one Groovy-specific member that was added, called "metaClass" (there were others, I didn't get a good enough look at the screen). Apparently this is necessary for the testing framework they want to use, which is named Spock.

Am I right to be concerned about this? Does it matter?

* I've been told this is for technical reasons that have to do with the way the application is built. I've been told that this does not apply to all classes, but to some.

2 Answers 2


The information that they gave to you is wrong.

Groovy can interact with Java classes without problems. In fact, most the the Spock core classes are Java (.java) not Groovy classes.

The problems about testing Java classes with Groovy are caused by Maven (well not Maven directly, but by the plugins in charge of compilation and execution of tests).

For some reason the interaction between the Groovy plugin and the Maven test plugin (surefire) sucks. (See the UPDATE it doesn't sucks in recent versions of GMaven).

I ran into this problem a long time ago. Which probably is caused by how the classloader for the test execution is setup. I can't give you an answer on how to fix that Maven Groovy/Surefire compatibility problem, because at that time instead of trying to fix it I took the fastest path for me: I switched from Maven to Gradle.

And about the differences on compilation... don't do the .java to .groovy rename. Groovy is a wonderful dynamic language, and is easy to migrate from Java to Groovy. But is not exactly the same language, there are some little differences to take into account: http://groovy.codehaus.org/Differences+from+Java

So if you rename the files automatically for the testing, there is a good chance that some things doesn't compile like array literals, or they compile with a different semantic like ==.

So my advice is: Spock is a wonderful framework for testing, and Groovy can save you a lot of repetitive code. You can migrate all to Groovy, but that decision requires more evaluation of the technical aspects of your project. If you want to use Groovy for tests and Java for main classes, look for a solution in the Maven community or try switching your build to Gradle.

Additional note: The Groovy compiler is a superset of the Java compiler. When a .java file is given to the Groovy compiler it uses the Java compiler. It means that you can mix .java and .groovy in the same directory and use the Groovy compiler to compile all. Maybe that setup helps you with the Maven test plugin.

UPDATE: Recently I've to work with a project using Spock and Maven 3. Making both to coexist is easier than before :)

First, configure your GMaven plugin, you can see an example here: https://gist.github.com/xlson/1253342

Then you have to configure Surefire so it sees your test classes:


The trick is in the regex expression since according to Surefire docs it applies to classes (if you don't use regex it applies to source files).

  • Hi Diego, what exactly do you mean by "For some reason the interaction between the Groovy plugin and the Maven test plugin (surefire) sucks."? Jul 4, 2013 at 13:46
  • That happened with a previous version of GMaven (see my UPDATE in the answer). What happened before is that Surefire didn't saw any test case compiled with Spock. There were two possible causes for that: 1. how Surefire handles patterns, 2. GMaven support for Groovy compiler extensions. (1) is fixed by the workaround that I've put in the UPDATE comment, (2) is fixed by latest versions of GMaven... so now everthing should work :)
    – Diego
    Jul 4, 2013 at 19:56
  • Thanks for the clarification: I might give it a try myself... Jul 4, 2013 at 22:37

As far as I know, it is possible to write your unit tests in Groovy (.groovy files) while your actual application code stays pure Java, as long as your tests do not assume the use of advanced groovy features on top of Java application classes (such as mixins and categories - which decorate the Java class with a metaClass). From Groovy you can test POJO's getters and setters using standard java calls, without having the the boilderplate testing code that you often have in Java. Groovy also allows you to easily implement mock objects of specific classes for testing (useful when testing API compliance for instance).

Groovy always has access to Java classes on the classpath. You just need the right libraries in the classpath used for testing and enable groovy compilation on your test sources. Just like the JUnit jar files are only used for unit tests, so can the groovy-all binary distribution be included during testing, but not be included in the class path at compile or run time of the application source itself.

I have no history with the Spock framework itself though, so I cannot comment on the validity of the information in that regard.

What it boils down to: as long as you compile your application classes using a java compiler (and not a groovy compiler), you will have the same byte-code, no matter what testing framework you use.

  • "as long as your tests do not assume the use of advanced groovy features" I think the problem is that the Spock framework uses those advanced features to inject mock classes into other classes, thus requiring some classes to be compiled using the groovy compiler. Which is what my concern really is: We're testing the Groovy version of our code, not our original Java code. I personally would like to just export a single jar to the testing project, but I've been told that won't work here (Groovy, advanced features, injecting mock objects that span many layers, etc)... so should I be concerned? Feb 27, 2013 at 15:02
  • I have not really read up on Spock much, but I see no reason why your application code would need to be compiled with Groovy instead of Java compiler. The tests themselves would be compiled with groovy, and the mock objects would be groovy classes, since there is no problem injecting these groovy classes into the Java application for testing.
    – RudolphEst
    Feb 27, 2013 at 15:12
  • Maybe you could ask the developers of Spock this question? Also, ask your dev team (or whomever suggested Spock) to create a simplified mock project with similar dependencies and functionality to your current project. Let them write the tests using Spock (if they have the time to waste). You should be able to make a better determination of risk versus development time saved and decreased code complexity from this POC. I always find a POC over the problem domain to be more enlightening than a plain old demo...
    – RudolphEst
    Feb 27, 2013 at 15:17
  • 1
    Looking at this example, it is quite clear that testing a stack can be done, and there is no reason why the stack cannot be a simple java compiled class, as long as the class is in groovy's class path when executing the tests.
    – RudolphEst
    Feb 27, 2013 at 15:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.