Thursday, June 4, 2009

Integration Testing Grails Controllers

If you are planning on running integration tests on your Grails controllers it would be good to know how to test your controller regardless of whether it simply returns the model or uses the render method.

When your controller returns a model you can simply test the return type.

Given:

def show = {
def bookInstance= Book.get( params.id )
return [ bookInstance: bookInstance] }
}


You test it by:

def model = myController.show()
assertNotNull model.bookInstance

or some such.

If you use the render method in your controller then you would use the ModelAndView object in your controller.

Given:

def save = {
def bookInstance = Book.get(params.id)
render(view:'create',model: [ bookInstance : bookInstance ])
}

You can test it as follows:

bookController.save()
assertNotNull bookController.modelAndView.model.bookInstance

There is one nasty caveat to the render method, and that is if you are rendering a template instead of a view. This is common when you are doing AJAX type calls that only return a partial page. The problem is that Grails will not populate the modelAndView map at all. Nor does render provide a return type.

The answer came from the following mailing list posting:

http://www.nabble.com/Testing-Controller-with-render(template:....)-td18757149.html

Essentially you need to alter the behavior of the render method. You can do this in the setup as follows:

def renderMap

protected void setUp() {
super.setUp()
BookController.metaClass.render = { Map map ->
renderMap = map
}
}


Then Given:


def bookSummary = {
def bookInstance = Book.get(params.id)
render(template: "bookSummary", model: [ bookInstance : bookInstance ])
}


And then you test your model values as follows:

bookController.bookSummary()
assertNotNull renderMap.model.bookInstance

I hope this is helpful.

Happy Grailing!

Thursday, May 7, 2009

Intellij 8.1.1 out with Grails 1.1 support

Intellij has reclaimed it's crown as uncontested King of Groovy/Grails IDEs with the release of 8.1.1. As many of you know, the release of Grails 1.1 introduced a number of improvements, in particular changes to dependency management and plugins, the testing plugin integration, etc. While all these improvements were great, the fantastic support for Groovy/Grails in IDEA broke.

Now with release 8.1.1 you can expect all the IntelliGrails goodness to return. As one who was using the EAP to get Grails 1.1 support I'm also happy to report that the Intellij team was highly responsive to our bug reports in particular the inability to debug integration tests. It all seems to be working in the last EAP and I'm downloading the Gold release now.

If I notice anything interesting I'll post again with my experiences.

Tuesday, March 31, 2009

Executing command line scripts from Groovy on Windows

Today I had the need to create a number of dependencies within my local Maven repository (I know it's a hack you Maven purists, back off). I decided that I would use Groovy to loop over the jars in the lib directory and create the a dependency for each file. Groovyists know how easy this is:

new File('.').eachFile{
//do something
}


And of course I was aware that on Windows you have to use a "cmd /c" prior to your executable. So my final was going to look like this:


new File('.').eachFile{
groupId = it.name.substring(0, it.name.size() - 4)
"cmd /c mvn install:install-file -DgroupId=blahzy.blah-DartifactId=${groupId} -Dversion=9.9.9 -Dpackaging=jar -Dfile=${it.name}".execute().text
}


Seems appropriately short and succinct for my groovy instincts to feel okay with it. Only problem is that it didn't work. When I would run it the console would freeze and I had no idea what was going on. After reading through some of the groovy documentation online I found out that if the output is too much the Windows process will just freeze. Luckily there was a documented "hack" to solve the issue. My final script:


new File('.').eachFile{
groupId = it.name.substring(0, it.name.size() - 4)
thisCommand = "cmd /c mvn install:install-file -DgroupId=blahzy.blah-DartifactId=${groupId} -Dversion=9.9.9 -Dpackaging=jar -Dfile=${it.name}"
proc = thisCommand.execute()
proc.consumeProcessOutput()
}


So I don't get any of the output but it worked so who am I to complain.

Tuesday, December 16, 2008

SacGRU the Sacramento GRoovy (GRails) Users

I've created a google group for all you interested in the Sacramento Groovy User's Group. The address is:

http://groups.google.com/group/sacgru

If you are interested, please sign up so that I can notify you of plans, upcoming events, etc. I'm very excited at the prospect of bringing the Development Productivity of Groovy and the Grails platform to the Sacramento Area. Imagine the cost savings to the California State Government if they built all their Web Applications using Grails. Goodbye 42 Billion dollar debt!

Sunday, December 14, 2008

Who wants a Sacramento Groovy User's Group?

I've been thinking for months about pursuing creating a Sacramento Groovy User's Group. Right now I'm trying to gauge the interest. I've talked to folks at the Sacramento Java User's Group and there was some interest there. Please ping me if you are in the Sacramento area and something like this would appeal to you.

My basic plan is to meet once a month and do the following types of sessions:
  • Vendors coming in pimping their products that use groovy in some way
  • Developers showing off the work they're doing with Groovy
  • Talks on various Groovy related technologies (Grails, Griffon, etc)
  • Open discussion
  • Lightning talks
  • Code reviews
  • Mini-code camps ("let's build something that does X")
...and of course I'm completely open to suggestions on other topics/formats, etc.

In order to make this work primarily I need interested people. I've already got ideas for sponsors (facilities, food, etc.).

Please hit me up if you're interested in participating in any way.

Monkey Search