rspec users - Mar 2009 - [Rails] specifying that a layout yields?

I recently had a bug in a layout due to the layout not calling "yield"
to display the actual content. I wanted to write a spec to describe
what was missing, but it wasn''t obvious how, so I just fixed the
problem first and doubled back to spec it later.

Anyway, the most succinct thing I was able to come up with was the
following:

  # http://gist.github.com/87246
  describe "/layouts/application" do
    it "should show the content" do
      class << template
        attr_accessor :did_render_content
      end
      template.did_render_content = false
      render :inline => "<% self.did_render_content = true
%>", :layout => ''application''
      template.did_render_content.should be_true
    end
  end

But I''m not quite satisfied with this, as it''s not as clear
and
expressive as specs usually are. I thought I''d write a custom matcher
for it, but it''s not obvious to me what I''d even want the spec
to look
like.

Any ideas?

Thanks,

Brandt

On 29 Mar 2009, at 02:33, Brandt Kurowski wrote:
> I recently had a bug in a layout due to the layout not calling
"yield"
> to display the actual content. I wanted to write a spec to describe
> what was missing, but it wasn''t obvious how, so I just fixed the
> problem first and doubled back to spec it later.
>
> Anyway, the most succinct thing I was able to come up with was the
> following:
>
>  # http://gist.github.com/87246
>  describe "/layouts/application" do
>    it "should show the content" do
>      class << template
>        attr_accessor :did_render_content
>      end
>      template.did_render_content = false
>      render :inline => "<% self.did_render_content = true
> %>", :layout => ''application''
>      template.did_render_content.should be_true
>    end
>  end
>
> But I''m not quite satisfied with this, as it''s not as
clear and
> expressive as specs usually are. I thought I''d write a custom
matcher
> for it, but it''s not obvious to me what I''d even want the
spec to look
> like.
>
> Any ideas?
>
> Thanks,
>
> Brandt
That''s some pretty nifty code Brandt :)

Did you consider testing this aspect of the view''s behaviour from a  
higher-level Cucumber acceptance test? I think that''s what I would  
have probably done.

Matt Wynne
http://beta.songkick.com
http://blog.mattwynne.net

On Sat, Mar 28, 2009 at 9:33 PM, Brandt Kurowski
<brandtkurowski at gmail.com> wrote:
> I recently had a bug in a layout due to the layout not calling
"yield"
> to display the actual content. I wanted to write a spec to describe
> what was missing, but it wasn''t obvious how, so I just fixed the
> problem first and doubled back to spec it later.
>
> Anyway, the most succinct thing I was able to come up with was the
> following:
>
> ?# http://gist.github.com/87246
> ?describe "/layouts/application" do
> ? ?it "should show the content" do
> ? ? ?class << template
> ? ? ? ?attr_accessor :did_render_content
> ? ? ?end
> ? ? ?template.did_render_content = false
> ? ? ?render :inline => "<% self.did_render_content = true
> %>", :layout => ''application''
> ? ? ?template.did_render_content.should be_true
> ? ?end
> ?end
>
> But I''m not quite satisfied with this, as it''s not as
clear and
> expressive as specs usually are. I thought I''d write a custom
matcher
> for it, but it''s not obvious to me what I''d even want the
spec to look
> like.
>
> Any ideas?
There''s no need for a custom matcher. You just utilize the :layout
option that render has. e.g. the follow example ensures the layout
renders the content it is given (via a yield block):

describe "layouts/application.html.erb" do
  it "should render the context given" do
    render :text => "foobar", :layout =>
"layouts/application.html.erb"
    response.should include_text("foobar")
  end
end


>
> Thanks,
>
> Brandt
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


-- 
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

On Mar 30, 3:39 am, Matt Wynne <m... at mattwynne.net>
wrote:
> On 29 Mar 2009, at 02:33, Brandt Kurowski wrote:
> > I recently had a bug in a layout due to the layout not calling
"yield"
> > to display the actual content. I wanted to write a spec to describe
> > what was missing, but it wasn''t obvious how, so I just fixed
the
> > problem first and doubled back to spec it later.
>
> Did you consider testing this aspect of the view''s behaviour from
a
> higher-level Cucumber acceptance test? I think that''s what I would
> have probably done.
Thanks Matt. It was actually a Cucumber feature that found the bug
(this is a new project that I''ve yet to actually open a browser on, I
think), so in that sense it''s already covered. But I wanted to somehow
specify this very particular piece of behavior so that in the future
if someone breaks it, there''s a spec that points right to the problem.
I think that if someone breaks my layout this way (e.g. accidentally
removing the yield in a future edit), most (all?) of my acceptance
tests will fail but it won''t be immediately obvious why.

Brandt

On Mar 30, 9:56?am, Zach Dennis <zach.den... at gmail.com>
wrote:
> On Sat, Mar 28, 2009 at 9:33 PM, Brandt Kurowski
> > ?#http://gist.github.com/87246
> > ?describe "/layouts/application" do
> > ? ?it "should show the content" do
> > ? ? ?class << template
> > ? ? ? ?attr_accessor :did_render_content
> > ? ? ?end
> > ? ? ?template.did_render_content = false
> > ? ? ?render :inline => "<% self.did_render_content = true
> > %>", :layout => ''application''
> > ? ? ?template.did_render_content.should be_true
> > ? ?end
> > ?end
>
> There''s no need for a custom matcher. You just utilize the :layout
> option that render has. e.g. the follow example ensures the layout
> renders the content it is given (via a yield block):
>
> describe "layouts/application.html.erb" do
> ? it "should render the context given" do
> ? ? render :text => "foobar", :layout =>
"layouts/application.html.erb"
> ? ? response.should include_text("foobar")
> ? end
> end
Doh! Looks like I was so focused on the mechanism behind the failure
that I ended up writing my spec for the details of the implementation
rather than just the desired behavior. Thanks for pointing out what in
retrospect should''ve been obvious Zach.

Brandt