> > > > If i have a view that calls "render :partial => 'foo'" and I don't use > > expect_render I want it to yell at me saying an unexpected call was > > made on the template. > > There's nothing else in rspec_on_rails that yells at you because you > don't like to organize your specs the way rspec thinks they should be > organized, so I definitely wouldn't support this being default > behaviour.
It was worth a shot. > > I could see, maybe, the possibility of having a command like > disallow_unexpected_renders or something like that, but I honestly > don't see that much value in it in return for the additional > complexity (didn't you start by saying this was too complex already?). To summarize for anyone else reading this or possibly picking it up in an archive down the road. I was wanting to have a one to one, view to spec. If I had a template called "show.html.erb" I want a "show.html.erb_spec.rb". If "show" had an inline call to render the partial "foo" I want to have a "_foo.html.erb_spec.rb" to test that partial. The one way I see how this can work is to have rspec_on_rails treat all inline render calls as expectations. This would result in a "unexpected call to render :partial => 'foo'" when I ran my "show" spec if I didn't have an "expect_render :partial => 'foo'" line. I do not want to be able to test the contents of the partial "foo" inside of my "show" spec. The reasons I do not want: - possibly multiple view specs testing the same partial - possibly multiple places for each partial to be tested, I'd rather make it easy to know where to go when updating a view and its spec - to add time for a developer having to search for what view a partial is being rendered in and then checking to see if that view's spec is testing the contents of the partial I do want: - consistency, expect_render is an expectation, let it be consistent with how expectations work, I should not get a passing test by potentially rendering the wrong thing - ease of maintainability and readability (which I see a single location is easier to maintain and read then potentially multiple spots) I see the convention of one view to one spec adding more value then it takes away. I may be a little to hardcore though, I also think that "integrate_views" in controller specs should just go away. > > I understand that you DO see value in this, and I'd encourage you to > write a plugin that makes this work the way you want and feel free to > publish it. > I think I'll have to give that a try. Thanks David, Zach _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
