[rspec-users] Nosy controller specs

Andrew Premdas apremdas at gmail.com
Thu Dec 11 07:33:32 EST 2008

Looking at this a bit further, it seems in Rails controllers decide how
things are got from Models i.e. by calling a class Method. I sort of forgot
this for a bit. So with this pattern the testing is correct in reflecting
the design of Rails. Still, with my OO purist hat on, it feels like this
responsibility should be in the model not in the controller, and that Rails
has got it wrong here (fat controllers). Do other ruby frameworks take a
different approach?

2008/12/11 Andrew Premdas <apremdas at gmail.com>

> Looking at generated controller specs we tend to get something like
> describe PostsController do
>   describe "handling GET /posts" do
>     before(:each) do
>       @post = mock_model(Post)
>       Post.stub!(:find).and_return([@post])
>     end
>     def do_get
>       get :index
>     end
>     ...
>     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. Now it seems to me that I
> should only have to change my model specs when I make this sort of change,
> this implementation details is none of the controllers business
> So a couple of things
> 1) Am I right about this?
> 2) If so is there a better way to still use the mock for speed but not be
> nosy
> 3) Should the default controller generators be re-written
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081211/0639a993/attachment.html>

More information about the rspec-users mailing list