How to stub message method in a controller

Hello Gang!  Based on the feedback from all you guys, here's a post about how easily can we stub the message method while writing controller Unit tests.

Lets take the example of my good old friend, YES the PersonController

Requirement:

After saving a person user should be redirected to show view, with a flash message indicating user was saved successfully.

Controller Code:
We have seen similar code in the past lets look at it again

We are not interested in code showing the action required if errors are returned while saving a person (As we had already covered that here)

Only different between the earlier code and this one is the flash.message and the use of message method.

How will we test it - How do they do it!:

In the grails environment, a method called message is dynamically added to the instance of PersonController, but how do we write a unit test for this?

All our controller test cases have been extending ControllerUnitTestCase which adds a lot of utility methods and fields to the controller instance.  But unfortunately it does not stub out the message method.  Hence, to test the above code we will have to stub out the message method manually. How? remember metaClass technique from my earlier post we will apply it here as well.

1. Stub out the save method (on the person instance ) to return true, using the metaClass of Person
2. Add a dummy message method on the controller instance, again using the metaClass of controller
3. Assert that flash.message was correctly set by the PersonController 
4. Remember to remove the metaClass of Person using which we stubbed the save method using the GroovySystem class.  (For explanation on why is this necessary see this post)

   
Test code looks like this:

If you notice we didn't use removeMetaClass for the controller instance. Why? because our test case extends ControllerUnitTestCase which creates a new instance of the controller class under test (in this case PersonController)before every test case is run. And hence we don't bother to use the removeMetaClass for the controller instance.

That's all folks!  As we can see metaClass is a real boon for unit testing

As uaual feedback, comments and complaints are welcome as always!

Unit testing Grails Controller - Part - 3

Alright folks this is the third and final installment of Unit Testing Grails Controller series.

In the last post I explained how we could write a test case where controller returns a model that could be used by view to render itself.

In this post we will see how we could write tests for situations in which controller has to render a view (may be to show validation errors while saving a instance of domain class)

Tired of repeating, but will say it again anyways, taking an example of a controller that performs CRUD on Person domain class lets call it PersonController

Requirement:

If an error occurs while saving a person, controller should re-render the create view showing the error so that user can rectify the error and try again.

Controller Code:
The controller code that will do the job for us looks like

How will we test it - How do they do it!:

Again, in the grails environment, save method on a person instance will actually fire an insert statement, but do we really want to do that while writing a unit test for PersonController?  The right answer is NO.  10 Points if you get that right!

So what are we doing in the above code sample.

1. Creating a person instance using the request parameters
2. Try to save the person created in the previous step
3. If save fails render the create view and return from there (Guard clause is an import pattern which deserves a post for itself)
4. If save succeeds redirect user to show view.

We should have a unit-test, for each of the above steps.
We already know how to write test case for step 4 from the first post

Lets focus on the first three steps.  There are two ways in which we can test the above code.  A longer and a shorter way!  And yes you guessed it, I will show the longer way first :)

Method 1: 

1. use mockDomain(Person) to add the save dynamic method to person instance
2. From the test code, we could populate the params map with invalid values
3. Those params would be used to construct the Person instance
4. While saving the person instance constraints will be fired, which will fail because of invalid values
5. This will cause the save method to return false and hence if condition will be satisfied causing the render to execute.
6. ControllerUnitTestCase class provides us a convenient property called modelAndView using which we can assert that controller actually renders to the create view

The test class code to demonstrate the above method is as follows

Although we should have written another test case to assert that the model was correctly populate by the controller but for the sake of this blog I have shown the assert in single test case.

Now that you have the Grails power, don't go anywhere!  I promise, will not bore you for long.  Here's the Method 2 of testing the above code.

Method 2:

1. Stub out the save method (on the person instance) to return false manually, using the metaClass of Person
2. use the modelAndView property to assert that controller actually renders the create view
3. Remember to remove the metaClass using which we stubbed the save method using the GroovySystem class.  If you don't do this then the metaClass setting will interfere with other tests that use the save method.  Because of this, some test cases could misteriously start failing when, run along with other tests and pass when run individually.  Such a situation is extremely difficult to debug and fix.  This is the single most common mistake people do while using metaClass.  Take my advice, Dont do it!

Short and simple isn't it.  lets look at the test code.

See its pretty easy to randomly add/stub methods using the metaClass.  Its a really powerful tool but as Spider Man's uncle Ben once said

With great power comes great responsibility!

use it responsibly!

Here, I conclude the three part series to demonstrate art of Unit Testing the grails controller. 

I hope you liked reading it as much as I liked writing it.  Feedback, Comments and Complaints are welcome as always!