The February issue of GroovyMag is out and has some great articles – including one on how to create a plugin for Grails written by yours truly. You can download the issue from the GroovyMag website. Enjoy!
I’ve made some changes to the Grails code-coverage plugin to support Grails 1.1. If you’re using Grails 1.1-beta2, you can try it out by running grails install-plugin code-coverage.
Documentation can be found at http://www.grails.org/Test+Code+Coverage+Plugin
This past week I presented on Groovy/Grails to a group of developers here in Minneapolis. Afterwards we had a panel discussion (fishbowl style) and dove into a wide array of topics ranging from dynamic vs. static typed languages, when to consider using Groovy/Grails and when NOT to. It was a great discussion and it was fun to hear so many different perspectives.
I’ve posted a few links for those interested in in learning more and the slides can be seen on SlideShare: Groovy Grails DevJam Jam Session
Luke Daley pointed out that there’s an open issue on the Groovy task list that would help with better Cobertura support for Groovy:
http://jira.codehaus.org/browse/GROOVY-3118
Cobertura support is already pretty good, but there are some cases where coverage doesn’t quite show up at 100% when it should.
Go set up a profile, login, and vote!
I was watching the output of my Grails unit tests and noticed that tests using the mockDomain feature of the new Testing Plugin seemed to run just slightly slower than straight up unit tests. This makes sense, as these tests are doing some meta programming magic to add mock dynamic methods and also remove them after each test run – and that takes a little extra time. But time is the enemy of testing, and I want my tests to run as fast as possible. That way I’m not discouraged from writing them or running them on a consistent basis.
So I’ve started writing tests a little differently and have been trying to reduce the number of times setUp() and tearDown() are called within a test class. This is probably a good practice, regardless of the unit testing mechanism you’re using. Here’s an example – I used to have really verbose test methods, like this:
testFirstNameBlankConstraint(){...} testFirstNameNullableConstraint(){...} testFirstNameMaxSizeConstraint(){...} testFirstNameValid(){...}
I like this pattern because each test method tested one thing – so if the test method failed, it was pretty obvious what went wrong.
However, setUp and tearDown methods were being called for each of these test methods which added some extra time to run the test suite. In a relatively small project, the time is so negligible it doesn’t matter. But on a large project with thousands of tests, it can be a noticeable difference.
Now when I’m writing my tests, I set ‘em up more like this:
testFirstNameConstraint() { // some test code assertEquals ("blank constraint", ..., ...) // some test code assertEquals ("null constraint", ..., ...) // some test code assertEquals ("max size constraint", ..., ...) // some test code assertEquals ("valid", ..., ...) }
In this example, the same testing is occurring, but I have only one test method instead of four (three less calls to setUp and tearDown). By passing a message as the first parameter to the assertions, I can still quickly determine which assertion failed, and my test suite runs more quickly.
