On Dec 17, 2007 8:43 AM, David Chelimsky <[EMAIL PROTECTED]> wrote:
> On Dec 16, 2007 11:03 AM, Jonathan Linowes <[EMAIL PROTECTED]>
> wrote:
> >
> > btw, to answer the same question for member actions (such as show), you
> can
> > stub or assert the association proxy class
> >
> > @article = current_user.articles.find(params[:id])
> >
> > then,
> >
> > it "should find article scoped by current_user" do
> > article = mock_model(Article)
> > current_user.should_receive(:articles).and_return(Article)
> > Article.should_receive(:find).and_return(article)
> > get :show, :id => article.id
> > end
> >
> > this will ensure that your controller is not calling Article.findunscoped
>
> I tend to take this one more step. I'm a bit of a demeter zealot, and
> I'm also usually writing the examples from the code first. So I'd do
> something like:
>
> it "should find the current users articles" do
> article = mock_model(Article)
> current_user.should_receive(:find_article).with("1").and_return(Article)
> get :show, :id => "1"
> end
Where is current_user defined here? I've always stubbed current_user on the
controller object. How are you doing this one?
>
>
> This would lead me to add a find_article method to User:
>
> describe User do
> it "should find it's own articles" do
> user = User.new
> user.articles.should_receive(:find).with("1")
> user.find_article("1)
> end
> end
>
> This has two benefits:
> - each example is simpler and focuses on one object and how it behaves
> - I can change the relationship between a User and it's Articles
> without changing the controller code.
>
> FWIW,
> David
>
>
> >
> > linoj
> >
> >
> >
> >
> > On Dec 3, 2007, at 5:44 AM, Daniel N wrote:
> > Assuming that there is a call like this in your controller
> >
> > @articles = current_user.articles
> >
> > One way to do this is to stub out the controller.current_user to return
> a
> > mock object of the current_user
> >
> > Then put an expectation on the current user that it's articles method
> gets
> > called. (return a mocked collection of articles)
> >
> > Then check that @articles is set to the returned mocked collection of
> > articles from current_user.articles
> >
> > phew...
> >
> > Ok So one way you might write this could be (This is untested...)
> >
> > it "should scope the articles to the currrent_user" do
> >
> > user = mock_model(User)
> > articles = [mock_model(Article)]
> >
> > controller.stub!(:current_user).and_return(user)
> > user.should_receive (:articles).and_return(articles)
> >
> > get :index
> >
> > assigns[:articles].should == articles
> >
> > end
> >
> >
> > Like I said though, that's not tested itself. If that's not exactly
> > right... it's along the right track of an option that can work.
> >
> > HTH
> > Daniel
> >
> > On Dec 3, 2007 9:07 PM, Stefan Magnus Landrø <[EMAIL PROTECTED]>
> > wrote:
> > > Typically, I'd write a method in your user model that returns the
> user's
> > articles:
> > >
> > > class User do
> > >
> > > def find_articles_for_user
> > > Article.find(:all, :conditions => ['userid = ?', id)
> > > end
> > >
> > > end
> > >
> > > Then you'd use a mock in your controller spec, and make sure you test
> that
> > your method is being called.
> > >
> > > On the other hand, the user model should be tested directly against
> the
> > db.
> > >
> > > HTH,
> > >
> > > Stefan
> > >
> > >
> > > 2007/12/3, Fischer, Daniel <[EMAIL PROTECTED]>:
> > > >
> > > >
> > > >
> > > > Let's say you're using the restful_authentication plugin.
> > > >
> > > >
> > > > You have a model called articles. On the index action of the
> > articlescontroller you simply want to spec out that it'll scope the
> results
> > to the ownership of the current_user.
> > > >
> > > >
> > > > It should NOT include any articles other than the articles that user
> > owns.
> > > >
> > > >
> > > > How would you properly spec this out?
> > > >
> > > >
> > > > Thanks for the help!
> > > > _______________________________________________
> > > > rspec-users mailing list
> > > > rspec-users@rubyforge.org
> > > > http://rubyforge.org/mailman/listinfo/rspec-users
> > > >
> > >
> > >
> > >
> > > --
> > > Bekk Open Source
> > > http://boss.bekk.no
> > > _______________________________________________
> > > rspec-users mailing list
> > > rspec-users@rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-users
> > >
> >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users@rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users@rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
