Skip to main content

Groovy Mocks and Java Classes

Trying to convert a Java/EasyMock based JUnit test to Groovy in the last couple days led me to find what I think is a bug in Groovy's MockFor class.

The documentation for MockFor says to use the proxyDelegateInstance method when testing Java classes, but unfortunately the delegate proxy obtained using that method is type-incompatible with the Java class you're trying to mock if that class is concrete.  It works for Groovy classes, all abstract classes, and all interfaces, but it appears to fall down when given a plain, concrete Java class.


Take this contrived Java class:

A simple collaborating class:

And a JUnit that mocks JavaClass to test CollaboratingClass:

This test will fail under Groovy 1.8.6 because the javaClassInstance won't actually be type compatible with Java class!

Wrapping that class in an abstract class or a Groovy concrete class works around the issue, but that adds some unnecessary complexity to using Groovy to test existing Java classes.

Comments

Post a Comment

Popular posts from this blog

Java command line app with Spring and Gradle

Many Java developers have had to build a command line app for one reason or another over the years, and there are many(!) ways to do it.  There are a bevy of command line libraries, some people roll their own when they get to this point (which is one reason why there are so many command line libraries!), and others just pull in the arguments simply and directly, eschewing a library. However, writing a tool, a developer should just focus on the meat of the problem rather than having to worry about the enabling functionality that allows it to work.  The Spring Framework very much supports this approach to development with its inversion of control (IoC) container and a myriad of other features. To support that approach for command line applications, the spring-cmdline library provides a bridge between the Spring framework and the JOpt Simple command line library. This tutorial will show how to leverage the spring-cmdline library to stand up a very simple command line ap...

manifest classpath + taglib jars + Tomcat = FAIL

I found an interesting side-effect of using manifest classpaths in our application jar files as it applies to taglib jar dependencies and embedded Tomcat 6. ·          Manifest classpaths do not appear to be expanded in the URLClassLoaders that load the jars with the manifests, so only the jar file referenced directly on the classpath are included in its URLs. The taglib search mechanism in Tomcat 6 (haven't checked Tomcat 7 to see if there's a difference) only walks the classpath looking for URLClassLoaders, looking at the underlying JAR URLs. Thus, if the taglib jar is referenced only as a dependency in the manifest of the main jar file and is not specifically on the classpath, it will not be spotted and use of that taglib by the JSP engine will throw an exception. This problem won’t actually show up in tests as IDE environments and builds generally include all the jar files in the classpath, so this one will bite you at runtime. ...