up vote 2 down vote favorite

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.

share|improve this question

1 Answer

up vote 3 down vote

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.

share|improve this answer
"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? – FrustratedWithFormsDesigner yesterday
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 yesterday
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 yesterday
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 yesterday

Your Answer

 
or
required, but never shown
discard

By posting your answer, you agree to the privacy policy and terms of service.

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