Showing posts with label Grails. Show all posts
Showing posts with label Grails. Show all posts

Sunday, 3 June 2007

Grails 0.5.5 - testing controllers with Mocks and Expando

In this blog entry I would like to show you how to unit test a typical 'update' action in Grails using Groovy Mocks and the ExpandoMetaClass.

Let's assume we have an action like this:
 
 def updateword = {
     def word = Word.get( params.word_id )
     if(word) {
         word.pl = params.word_translation
         if(word.save()) {
             render("OK")
         }
         else {
             render("Error updating word")
         }
     }
     else {
         render("Word does not exist")
     }
 }
In brief, it updates a Word instance by getting a Word from the database, modifying its 'pl' property and saving it back to the database.

Now, how would you unit test the execution path where the "Error updating word" message gets rendered? To do that, you need a scenario where a Word instance gets returned from the database but fails to save back after the update operation. Here is how you can do it using Mocks and Expandos:
 void testUpdateExistingWordSaveFailure() {
     def mock = new MockFor(Word)
     def fakeWord = new Expando(save: {false})
 
     mock.demand.get { fakeWord }
     mock.use {
         def wc = new WordController()
         wc.params.word_translation = "tak"
         wc.updateword()
         assertEquals "Error updating word", 
                      wc.response.delegate.contentAsString
     }
 }

The flow of the test is as follows:
  1. Create a mock for the Word class
  2. Craete a fake word instance (Expando) which replaces the 'save' method
  3. Demand the Word class to return the faked word when the get method is called (exactly once)
  4. Use the mock and call the updateword closure
  5. Assert if the correct message was rendered to the browser
See the Unit & Integration Testing Controllers page to understand the last step - getting a text from the response.

Saturday, 26 May 2007

Grails 0.5 Unit Testing - other issues

I have mentioned already about slow unit testing in Grails 0.5. Apart from that, there are several other bugs:
Luckily, there are workarounds for all these bugs (good news if you are stuck). Check the grails-user group for more details (clicking one of the bugs above should take you to the description and solution).

The good news is, that all the issues seem to be fixed in the current 0.5.5 snapshot (downloaded on 26th of May)! Suggest that you give it a go, or even upgrade your projects to version 0.5.5.

Be careful however when upgrading to 0.5.5. Tests have been moved from 'grails-tests' to 'test' folder, therefore 'grails test-app' will give you:

No tests found in test/unit to execute ...
No tests found in test/integration to execute ...

As you can see, tests have been separated into two categories: unit and integration. I have noticed however, that unit tests for domain classes are being generated under the 'integration' test folder. Looks like a new bug, though more likely that the test separation has not been fully implemented (and tested :)) yet.

Update:
Actually, it is not a bug. Typical unit tests for domain classes in Grails are in fact integration tests with all the dynamic methods and properties injected by the framework. Plain unit tests can be created, too by running the grails create-unit-test command. Read more on the Grails Unit Testing page.

Monday, 21 May 2007

Grails Unit Testing not agile

Don't be surprised if you give Grails unit testing a try. I've done that recently and must say it is not agile at all. At least not yet (Grails 0.5).

As for now, it takes approximately 25 sec on a pretty fast box (my PC is a 3.2 GHz Dual Core with 2GB RAM, Os WinXp) to run a single unit test. Why so long? Surely, unit tests should run faster.

Update: I've just run grails test-app on my new Ubuntu 7.04. To my surprise, a single unit test run takes only 17 sec. That's a big difference comparing to 25 sec on WinXp.

I have found the answer on the grails user group. Graeme Rocher, the project lead of Grails, in reply to a similar issue says:
"We're separating out unit and integration tests so that unt tests will
run quicker. At the moment every test is an integration test, hence
why it takes long to bootstrap" (Graeme's post)

The slow unit testing should be improved in Grails 0.5.5, as Graeme is working on improvements to that. Can't wait to try this out as TDD on Grails can be really exciting then!

Apart from that there is another small issue, though. Some have already experienced that (see this post on the grails-user group), too. If a unit test fails it does not tell you what went wrong. All you can see is the 'test failed' message. Quite confusing, especially if you are used to JUnit's detailed error messages.

Luckily, you can find the cause. Again, the grails-user group is where I've found the answer. The detailed test reports sit under target/test-reports folder. They are available in different formats, including plain text, xml and html. You can find the detailed message there, plus a very long stack trace ;-) The only trouble is that you waste even more time finding the cause of a unit test failure...

And here I can give one hint that makes it faster. If you open one of the detailed reports in a text editor that checks for file modifications, it would reload the report automatically after each test run ;-)