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.
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:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.14</version>
<configuration>
<includes>
<include>%regex[.*Spec.*]</include>
</includes>
</configuration>
</plugin>
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).
3
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.
4