ControllerTest should handle default return from actions

I would need convincing this is worth the effort involved. render(model:...) is hardly typical (or even recommended), so I can't really see the benefit. And anyway, I think renderArgs should only be populated if the render() method is called.

How do you get access to the model used for rendering without using renderArgs?

Re: additional convincing...

What's the functional difference between:

def action =

and

def action =

If there is no functional difference, then having to unit test one way or unit test the other is allowing the implementation to bleed into the unit tests too much, which hurts refactoring and is generally a pain.

The issue I've got is that I'm trying to add unit tests onto a bunch of controllers, and there is no consistent code style – there's a mix of both render(model:...) and the default returns. And having to check the code's implementation to figure out how to write the unit test seems dirty, dirty, dirty.

Now, I could consistently execute something like:

def returnVal = controller.action()
def model = renderArgs?.model ?: returnVal

But that's just obnoxious.

If I submit a patch to make these things the same, would it get in?

That depends on the patch I'm just about persuaded that this issue makes sense, but I want a fairly straightforward solution - wrapping controller actions is not pretty. Actually, you might consider trying grails.test.AbstractClosureWrapper - it sends shivers down my spine to suggest it, but it may be the best option.

I'll do up a patch and we'll see where it goes.

Is there supposed to be a semantic difference between "return myModel" and "render(model:myModel); return"?

I've delegated the question to Graeme From the user's perspective, I can't see any semantic difference. The code path is certainly a bit different, but I don't know whether by much. Basically, I've never come across the render(model: ...) form.

There shouldn't be any semantic difference no