[rspec-users] expect_render, why does there need to be a warning
dchelimsky at gmail.com
Thu Aug 16 11:08:37 EDT 2007
On 8/16/07, Zach Dennis <zach.dennis at gmail.com> wrote:
> > >
> > > 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.
You can have that. But you don't have to. It's your choice.
> 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.
There is nothing stopping you from doing this.
> The one way I see how
> this can work is to have
> rspec_on_rails treat all inline render calls as expectations.
Again, there's nothing stopping you from doing this. There's nothing
forcing you to either. That's an important point.
> 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'"
> I do not want to be able to test the contents of the partial "foo"
> inside of my "show" spec.
If you're actually driving your design with the specs, which is what
rspec is designed to encourage, the way you do it is this:
Spec-drive a view. At the end of several red/green/refactor cycles
you'll likely have one spec and one view.
Spec-drive another view.
Recognize that both views display some of the same stuff.
Extract the common stuff into a partial.
This last step is refactoring: changing the design without changing
the behaviour. Refactoring, ideally, should not require changing any
specs. The way things are currently, after you extract the partial,
you can run the specs and they pass. With rspec forcing things to work
the way you seem to want it to, you couldn't change the design without
causing failing specs.
After you've refactored the design, extracting the partial, perhaps
you want to restructure the specs so that there is only one spec for
the partial. At this point, you create a new spec for the partial,
moving the examples from one of the two view specs to the partial
spec, and then remove the duplicate examples from the other.
BDD is a process, not a result. The tools should support the process.
What you're asking for would stand in the way of this process.
> 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
How can this happen if you're writing the specs first?
> - ease of maintainability and readability (which I see a single
> location is easier to maintain and read then potentially multiple
Again, there's nothing stopping you from getting to this.
> I see the convention of one view to one spec adding more value then it
> takes away.
There's a difference between convention and handcuffs. What you are
proposing is handcuffs. There is absolutely nothing stopping you from
following this convention.
> I may be a little to hardcore though, I also think that
> "integrate_views" in controller specs should just go away.
Again, while RSpec is opinionated in some ways, it also needs to be
flexible. Obviously there are boundaries to this, but you and I seem
to have these boundaries in different places.
The fact that the default is to not integrate views guides you in the
direction of strict isolation. But with strict isolation comes a cost,
which is that you can get all your component specs working and the app
doesn't run because you never had any integration tests. For some,
using integrate_views takes the place of having integration tests.
Although this is not the approach that I like to take, it is a
perfectly reasonable approach and I think it would be wrong for rspec
to disallow this.
> > 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,
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users