Potential issue when mocking in Groovy

The groovy.mock.interceptor.MockFor and grails.test.GrailsMock allow for mock objects in Groovy and Grails, respectively. I've been using both of these classes with good success for a long time. But recently, a small refactoring involving the the removal of a parameter from a method signature has caused me to re-evaluate the mock object usage in a dynamic language like Groovy.

As I said, there was a refactoring done on the public contract of a service, where the method name stayed the same, but a parameter was removed from the method signature. The contract unit tests for this service were changed to drive the refactoring ("test-driving the refactoring"). However, the collaboration unit tests, where this service is now acting a dependency, were not changed and they continued to pass successful. I tried cleaning the old .class files and compiling the Groovy tests, but to no avail, the unit tests which mocked this service continued to pass successfully, even though the method signature no longer existed on the real service implementation. After perusing the javadoc documentation, there does not seem to be any functionality in either of these classes to verify that the type that is being mocked has a method signature that matches the method signature being mocked. Therefore, these classes can mock methods which are non-existent on the real dependency implementations. Fixing the issue involved finding the method signature using a text search.

The whole episode was a bit unsettling; we have a lot of unit tests and we may be testing scenarios which are not representative of the real world. In my case, the real world scenario manifested itself as a runtime exception stating that the method was missing. In the case of Java and Mockito, the method signature change would result in a compilation error where the changed method signature was mocked in unit tests. My takeaway was to be more diligent with my refactoring and really ensure that I have changed all places in the code where a particular method is referenced.

In support of Groovy's dynamic method dispatch

Came across a design issue today where we really could have used Groovy's dynamic dispatch and multi-method support to invoke the proper method based on the interrogation of the runtime type of an object instance passed as a parameter to the method.  This blog posting by MrHaki gives a great description of how Groovy solves this problem without the need of a double dispatch pattern implementation.  We're writing our code in Java, so we don't get the Groovy goodness of dynamic method dispatch and multi-methods.  We resorted to a double dispatch implementation to solve our problem.  We did not use the instanceof operator and a whole bunch of conditionals.

Groovy Remote Control plugin via Maven

I had some issues getting the Groovy Remote Control plugin to pull down through Maven today.  The documentation that is currently in place today is not correct.  Here is the fragments of my Maven POM that enabled me to pull the plugin as a dependency:

 

 

Test-Driven in Groovy presentation in the bag

Joe Muraski and myself did a Test-Driven in Groovy workshop at GR8 in the US conference here in Bloomington, MN this past Friday. If you're interested in the materials (presentation, demo app), you can get it all right here. The demo consists of a Java web app with lots of opportunity for refactoring, Groovy unit tests, and Cucumber (via cuke4duke) acceptance tests.

Cool features in Cucumber, part 1

My Cucumber adventure (via cuke4duke) continues. I have been busy writing features and building out step definitions in Groovy. Groovy absolutely rocks for this sort of thing. I'm doing some more elaborate Cucumber features (at least in my novice head) and came upon this blog posting. Very handy stuff. More related to the Ruby version of Cucumber, but most of the concepts transfer over to cuke4duke.

DevJam course offerings for February-March 2010

David Hussman recently posted the new DevJam course offerings for February and March 2010. I'll be leading the Introduction to Groovy, Introduction to Grails and Test Driven courses. The Test Driven course is open to Java and .NET developers (.NET examples in C#). Detailed information can be found at http://www.devjam.com/courses-and-training/index.php. Seating is limited to about 12 participants per course.

Second Groovy and Grails training in the bag

Completed my second Groovy and Grails training for DevJam this past Saturday. This training session was much smoother than the first training. Still too much material and exercises to be taught in just one day. Received a lot of good feedback from the participants and hopefully this feedback helps solidify the training. I'm always amazed at how much stuff I could focus in on for the Groovy training. Really need to beef up the meata-object protocol stuff in the Groovy training.

Using the new Groovy-Eclipse V2 plugin

Started using the new Groovy-Eclipse V2 plugin. I'm continuing to fine tune some Groovy training that I've come up with in collaboration with DevJam. So far so good. Seems to work pretty well. I'm not expecting much at the moment, but the alpha seems pretty stable. We need an open source Groovy IDE for the training, and I would love to use Eclipse and this plugin to fulfill that role. I think I still prefer IntelliJ for Groovy stuff (it seems more mature), but it costs some money and most people are using Eclipse these days.

First Groovy and Grails training is in the bag

I made it through my first test run of Groovy and Grails training for DevJam this past Saturday. Had a couple of snafus occur. Nothing major and easily fixed. Did learn a couple of things though:

Don't put developers on an operating system that they don't know for training

The DevJam training has Mac minis which boot either Mac OS X Snow Leopard or Windows Vista (via Bootcamp). I had the systems booted to Mac OS X for the training. Unfortunately all of the developers that came to this training were unfamiliar with Mac OS X, but willing to try it. Bad move on my part. I ended up answering far too many questions on the operating system and which tools were were going to use. Oracle SQL Developer also gave me problems in the Mac OS X environment when trying to update the tool with the MySQL drivers through its software updating system.

If you think you have enough code examples, you don't!

I had about 10-12 Groovy code examples to demonstrate various features of the language. Far too few for the questions that cropped up. Luckily, it was Groovy and writing new code examples or changing existing code examples was pretty straightforward. Kudos to Groovy for being very easy to explore and play with. The participants thought very highly of the interactiveness of the coding during the session.

Don't try to do both Groovy and Grails in a single day.

I knew going in that doing both was going to be very difficult. I just didn't realize how difficult it would be. Again, due to operating system and tool snafus, I didn't finish up the Groovy stuff until well into the afternoon. Not much time for Grails. I was looking forward to the exercise in Grails and we didn't get very far with it.

Automate the packaging of the student materials in electronic format.

We decided to put all the training handouts, examples, and anything else helpful for the students on 4 GB flash drives and give the flash drives to the students to keep. That's good. What's not good is missing some things on the flash drive and updating flash drives during the course. Next time I'll use an Ant build script to build a distribution and clean out any Subversion metadata from the student materials.

The Groovy Eclipse plugin seems to be making headway.

One of the participants in the group, Nick Spilman, had his laptop along and was using Eclipse Galileo and the new Groovy Eclipse plugin during the Groovy portion of the training. He thought it worked well with Groovy. I used IntelliJ 9.0 EAP (Maia) and that also works well. Looks like SpringSource (or shall I say VMware now) is getting serious on the tooling for Groovy and Grails.

Need to spend more time on understanding Groovy's meta-programming facilities.

It's one thing to use Groovy and use its meta-programming faclities (aka MOP) successfully in your own work. It is a far different thing to try and teach others about Groovy's meta-programming facilities. Teaching a concept, especially a concept as complicated as meta-programming, is extremely difficult.

Performing test runs of presentations and trainings is essential.

I'm very pleased that I was afforded the opportunity to be able to offer a couple of test runs of this training to some developers before offering it to the public. Like anything else, it takes practice and feedback to get good at something. I have another test run of this training later this month and I'm sure it will be much better than it was the first time out.

Grails domain object modeling with Groovy enums

I had a need to use enumerations within my object model in my Grails app today. I wrote up a Google Sites page about my solution. I am using Grails 1.1 for this solution.

Having another look at Grails

It's been a while since I've really worked with Grails. I used it in 2007 for about 7 months, but we really didn't use it in a typical fashion, as the front end was done in Adobe Flex. 2007 was also fairly early in the life of Grails; I remember using version 0.5.6 when I started at the client.

I'm now building a sample application in Grails 1.0.4 and doing all the AJAX stuff in jQuery. I'm really impressed with Grails now! It's so much more productive than I remember it. Also, I have a couple of books that have been absolutely essential to getting me going with Grails again: The Definitive Guide to Grails, Second Edition and Groovy and Grails Recipes. I'm using IntelliJ IDEA 8.1 for all my development and its Groovy and Grails support is much better than I remember it. JetBrains really makes it easy to give them money every year for a personal license upgrade for IntelliJ.

I haven't been super pleased with the Grails documentation on the Grails site and hopefully SpringSource has a positive effect on this issue in the near future. My development has been plowing ahead very nicely. I really like that I don't have to restart the application server for every little change. That saves a ton of time and has a positive effect on your ability to stay focused on job at hand. Very impressed with Grails this time around.