[rspec-users] Nosy controller specs

Andrew Premdas apremdas at gmail.com
Thu Dec 11 14:28:47 EST 2008


Mark,

Thanks for your reply. As you say controllers should not be responsible for
defining things, but in Rails this is exactly what they do, they formulate
queries using class methods like find_by_xxx. Personally I think Rails is
somewhat confused or perhaps lax in defining Controller responsibilities
compared to many MVC frameworks and particularly to the underlying concept
of MVC.

As for this years posts being a presentation issue that depends. If the
request came from a view i.e. I'd like to see post for 2001 then the
controller should pass parameters to the model so it can return the correct
things. On the other hand if last years posts represent a specific business
concept something perphaps like AuditablePosts, then the model could/should
represent this as a seperate resource. In Rails all business rules don't
generally reside in the model, but maybe they should!

IMO of course :)

2008/12/11 Mark Wilden <mark at mwilden.com>

> On Thu, Dec 11, 2008 at 4:33 AM, Andrew Premdas <apremdas at gmail.com>wrote:
>
>>
>>>     it "should find all posts" do
>>>       Post.should_receive(:find).with(:all).and_return([@post])
>>>       do_get
>>>     end
>>>
>>> Now this last spec "should find all posts" is nosy is far as I'm
>>> concerned in that its specifying how the model should get all the posts
>>> (i.e. white box testing) rather than checking the result i.e. that its got
>>> @post back. So now if I change the model so that "all posts" is for example
>>> "all posts in last year" because there is a new business rule that we don't
>>> show posts over a year old then my controller spec fails.
>>
>>
> I think this is probably correct as is.
>
> When specing a controller, it's correct BDD to specify how it interacts
> with other objects. If the controller itself wants all posts in the last
> year, it's OK to test that. The fact that only this year's posts are of
> interest is a presentation issue - it's not an essential characteristic of
> the data. It's not the model's job to decide that all clients should get
> back posts in the last year, and hence that's what its find method should
> return.
>
> All business rules don't reside in the model. As soon as you say "we don't
> SHOW posts over a year," you're talking about a presentation rule, not a
> model rule. Controllers mediate between data and screen - they're
> responsible for getting the data to be shown. That code should exist in the
> controller and be tested there.
>
> On the other hand, the controller should not necessarily be responsible for
> defining what constitutes "all posts in the last year." That should very
> likely be a named scope.
>
> This is all just my humble opinion, of course, and might be utter rubbish
> in any particular real world situation.
>
> ///ark
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081211/5630921a/attachment-0001.html>


More information about the rspec-users mailing list