On Jun 20, 2010, at 10:34 AM, Wincent Colaiuta wrote: > El 20/06/2010, a las 15:09, David Chelimsky escribió: > >> >> On Jun 20, 2010, at 8:06 AM, David Chelimsky wrote: >> >>> On Jun 20, 2010, at 8:03 AM, David Chelimsky wrote: >>> >>>> >>>> On Jun 20, 2010, at 7:30 AM, Michael Schuerig wrote: >>>> >>>>> On http://github.com/rspec/rspec-rails under "View specs" there's an >>>>> example >>>>> >>>>> describe "events/index.html.erb" do >>>>> it "renders _event partial for each event" do >>>>> assign(:events, [stub_model(Event), stub_model(Event)]) >>>>> render >>>>> view.should render_template(:partial => "_event", :count => 2) >>>>> end >>>>> end >>>>> >>>>> Is this indeed correct? From the outset, it looks wrong because it sets >>>>> an expectation (view.should ...) after the call to render. >>> >>> Yeah - I see that this is confusing. Maybe we should change that to >>> view.should have_rendered("..."). If so, we should also change >>> response.should render_tempate("...") and response.should >>> redirect_to("....") in controller specs. >>> >>> WDTY? >> >> I'm also toying with an idea that would allow you to set an expectation >> before and have it evaluate at the end. Kind of like message expectations >> from the outside, but the underlying implementation would be different. > > Was going to suggest exactly that. > > Although the implementation would be different from normal message > expectations, I wonder if it could be built on top of them.
That's the idea. I'm working on a pub/sub API for events like example_started, example_initialized, example_executed, example_finished (do those names make sense to you?). You can see that work on the events branch of rspec-core: http://github.com/rspec/rspec-core/tree/events. Please feel free to provide any feedback on the direction - just note that it is preliminary and incomplete :) I'm pretty sure I'll be able to use that to write matchers that pause evaluation until they receive the example_executed message. >> Not sure if it would work, and I'm not sure if it would help (might just >> make things more confusing). WDYT? > > I'm not sure either, but I suspect it would be more consistent with the way > we set up our other expectations. > > ie. - when we are testing interactions, we usually use message expectations > that are set up beforehand > > - when we are testing state, we perform some action and then inspect the > state (usually expressed using present tense eg. "should be") > > The "should have_rendered" (past tense) idea doesn't really fit in, with > those two styles either conceptually or grammatically. This is an odd bird because it's delegating to a rails method named assert_template, which is intended to be evaluated after the action. The underlying implementation looks at a hash that AC::TestCase::Behavior builds up during the test, so it's not quite a message expectation (verifying upon receipt of the message). So I think have_rendered is more accurate, but you have to understand the implementation to understand that :) The other thing is that message expectations on real objects don't typically invoke the expected methods. In this case, the partial is actually being rendered, so putting "view.should render_template('...')" before the action could be confusing. One thought is to add a custom resolver that finds the first requested template for real, but then stubs out the remaining templates (a la the NullResolver used in controller specs). That would make controller specs and view specs work the same way, maybe with a render_partials method in view specs to tell it to render the partials (like render_views in view specs). An alternative would be to make the "view.should render_template" stub out the suggested template if called before the action? Then it would work a lot more like real message expectations. Thoughts? > > Cheers, > Wincent > > _______________________________________________ > 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
