A couple comments inline... On Thu, Mar 13, 2008 at 5:54 PM, __iso __ <[EMAIL PROTECTED]> wrote: > it "should call the login required" do > controller.should_receive.... > do :get > end
This is testing too much. Just stub the call to logged_in? or whatever > it "should call on the account.posts" do > @account.should_recei... > get :index > end There's no need for this. If your mocks are set up properly, then the only way for assigns[:post] to == your mock list of posts is if @account receives #posts. So this example duplicates some of the stuff that's implicitly tested in the next one, which is a much more useful example. > it "should assign posts" do > do_get > assigns[:posts].... > end > end > <snip> > > I am not trying to say that testing isn't good and that everyone is on > the wrong track, but rather wondering if, as in the example, am testing > more than I should be. Personally, I write tests when I feel that they will help me design my code better, give me confidence that the code works as expected, or serve as useful documentation. If you aren't benefiting from certain tests, then don't write them (*gasp*) Remember, BDD isn't some magical routine that, if followed, leads to perfect applications. It can be very helpful in achieving certain desirable ends, but it's not a substitute for your own thinking. Pragmatism and creativity reign supreme. Lately I've started to write fewer interaction-based specs (like the example you gave) when dealing with controllers. I tend to just make the request and let it go all the way down to the database, to make sure that everything is hooked up properly. The catch is that your controllers have to be super skinny - you should be able to cover an action with one or two examples - and have the majority of permutations be handled by the model (and thus covered with model specs). Pat _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
