How to test the layout of a controller?

Rails
1

I noticed this…

http://bjhess.com/blog/2008/04/27/five-rails-tips/

But it’s outdated a bit. What should I do? I get a DEPRECATION
WARNING: response.layout has been deprecated. Use template.layout
instead. but after googling around I can’t find a definitive solution.

It’s gotta be simple…

2

I noticed this…

http://bjhess.com/blog/2008/04/27/five-rails-tips/

But it’s outdated a bit. What should I do? I get a DEPRECATION
WARNING: response.layout has been deprecated. Use template.layout
instead. but after googling around I can’t find a definitive solution.

I use this with Rails 3 and RSpec…

require ‘spec_helper’
describe KidsController do
describe “GET index” do
before(:each) do
get ‘index’
end

it "should use the 'kids' layout" do
  response.should render_template('layouts/kids')
end

end
end

And in my KidsController I have the following line:

layout ‘kids’

3

daze wrote in post #970545:

I noticed this…

http://bjhess.com/blog/2008/04/27/five-rails-tips/

But it’s outdated a bit. What should I do? I get a DEPRECATION
WARNING: response.layout has been deprecated. Use template.layout
instead. but after googling around I can’t find a definitive solution.

It’s gotta be simple…

You shouldn’t be testing the layout of a controller. Instead, you
should be testing (with Cucumber) that the view has the content you
want.

Remember: test behavior, not implementation. You should ideally be able
to change
your whole implementation and still have all your tests pass.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

4

daze wrote in post #970685:
[…]

With regard to the idea about testing behavior alone:

That makes a lot of sense. A lot. My question, however, is about how
there must be a line to draw. If you were to test that the view has
the content you want, wouldn’t you HAVE to be testing implementation
to an extent, as your view contains tags like e.g.

, and you’d be testing for e.g. a div with id ‘main’?

Yes. That’s not implementation in the sense that the user actually
sees it.

It’s
just not clear to me how…

What part isn’t clear?

(…) You should ideally be able
to change
your whole implementation and still have all your tests pass.

Could you elaborate, maybe?

What do you need elaborated?

Also, as I’m just getting started
testing, I guess it’s good to know now: Is it okay to use Shoulda and
factory_girl_rails to handle all my testing? Or is rspec / cucumber
absolutely necessary? (I don’t feel like changing … but I guess I
need to know)

Use RSpec (or Shoulda) to test your models. Use Cucumber to test
user-facing behavior (don’t bother with controller specs). Use Factory
Girl everywhere (Pickle helps it talk to Cucumber).

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

5

First off, resolving my own issue:
Apparently, you can use “assert_template” to test the layout. In my
case, I could do

assert_template ‘static/home’,‘layouts/application’

which would work.

With regard to the idea about testing behavior alone:

That makes a lot of sense. A lot. My question, however, is about how
there must be a line to draw. If you were to test that the view has
the content you want, wouldn’t you HAVE to be testing implementation
to an extent, as your view contains tags like e.g.

, and you’d be testing for e.g. a div with id ‘main’? It’s
just not clear to me how…

(…) You should ideally be able
to change
your whole implementation and still have all your tests pass.

Could you elaborate, maybe? Also, as I’m just getting started
testing, I guess it’s good to know now: Is it okay to use Shoulda and
factory_girl_rails to handle all my testing? Or is rspec / cucumber
absolutely necessary? (I don’t feel like changing … but I guess I
need to know)

6

Alright. Here’s one roadblock.
So what I understand w/BDD is that I should write all these tests,
watch them fail, and then code to make the tests pass. But the error
messages I get from running tests don’t provide as much insight as
doing “rails server” and then seeing whatever error comes up… I
don’t understand how people do this.

7

Also, what’s becoming REALLY bothersome (I must not full understand or
something) is that my tests keep failing, but testing things with
rails server works fine! :(((

8

Please quote when replying.

daze wrote in post #970694:

Alright. Here’s one roadblock.
So what I understand w/BDD is that I should write all these tests,
watch them fail, and then code to make the tests pass.

No. Write one test, watch it fail, make it pass, refactor as
necessary. Then write the next test. Lather, rinse, repeat.

But the error
messages I get from running tests don’t provide as much insight as
doing “rails server” and then seeing whatever error comes up… I
don’t understand how people do this.

Probably by writing more atomic tests. Could you give an example test
that wasn’t as useful as you would have liked?

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

9

daze wrote in post #970696:

Also, what’s becoming REALLY bothersome (I must not full understand or
something) is that my tests keep failing, but testing things with
rails server works fine! :(((

Then you’re not testing the right things. Again, code would be helpful.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

10

On Dec 25, 11:44pm, Marnen Laibow-Koser [email protected] wrote:

daze wrote in post #970694:

Alright. Here’s one roadblock.
So what I understand w/BDD is that I should write all these tests,
watch them fail, and then code to make the tests pass.

No. Write one test, watch it fail, make it pass, refactor as
necessary. Then write the next test. Lather, rinse, repeat.

Does this apply to all tests - unit, functional, etc? I got my unit
tests working, but my functionals are not.

But the error
messages I get from running tests don’t provide as much insight as
doing “rails server” and then seeing whatever error comes up… I
don’t understand how people do this.

Probably by writing more atomic tests. Could you give an example test
that wasn’t as useful as you would have liked?

Sure. Navigating to a sections#show page yields a screen that says
“NoMethodError in SectionsController#show
undefined method `paginate’ for #Class:0x5eb4ad0”
so I immediately realize I need to check wherever I call paginate and
see if the method is implemented.

Running the functional test
ruby -I test test/functional/sections_controller_test.rb
Only yields this:

  1. Error:
    test: A section should respond with 200. (SectionsControllerTest):
    NoMethodError: undefined method `response_code’ for nil:NilClass

This doesn’t mean anything to me. (In my test, I had should
respond_with :success.)

11

daze wrote in post #970699:

On Dec 25, 11:44pm, Marnen Laibow-Koser [email protected] wrote:

daze wrote in post #970694:

Alright. Here’s one roadblock.
So what I understand w/BDD is that I should write all these tests,
watch them fail, and then code to make the tests pass.

No. Write one test, watch it fail, make it pass, refactor as
necessary. Then write the next test. Lather, rinse, repeat.

Does this apply to all tests - unit, functional, etc? I got my unit
tests working, but my functionals are not.

Yes. One test at a time on each level. Also, Test::Unit functionals
are needlessly painful. Use Cucumber instead.

My usual procedure:
Write a Cucumber story for functionality, watch it fail.
Figure out the first thing I need to do to implement that functionality,
write a unit spec in RSpec, watch it fail, make it pass.
Do next unit spec likewise.
When Cucumber story passes, feature is complete. Write another story.

But the error
messages I get from running tests don’t provide as much insight as
doing “rails server” and then seeing whatever error comes up… I
don’t understand how people do this.

Probably by writing more atomic tests. Could you give an example test
that wasn’t as useful as you would have liked?

Sure. Navigating to a sections#show page yields a screen that says
“NoMethodError in SectionsController#show
undefined method `paginate’ for #Class:0x5eb4ad0”
so I immediately realize I need to check wherever I call paginate and
see if the method is implemented.

Running the functional test
ruby -I test test/functional/sections_controller_test.rb
Only yields this:

  1. Error:
    test: A section should respond with 200.

“A section”? Which one? Make your descriptions more explicit.

(SectionsControllerTest):
NoMethodError: undefined method `response_code’ for nil:NilClass

This doesn’t mean anything to me.

How can that not mean anything to you, when it’s telling you exactly
what the error is?

(In my test, I had should
respond_with :success.)

You can step through with the debugger to see where it fails.

Also, RSpec and Cucumber have better error reporting than Test::Unit.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone
Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

12

Yes. One test at a time on each level. Also, Test::Unit functionals
are needlessly painful. Use Cucumber instead.

Okay. Shoulda / Test::Unit in functional tests are painful… I’ll
get back to you on Cucumber.

My usual procedure:
Write a Cucumber story for functionality, watch it fail.
Figure out the first thing I need to do to implement that functionality,
write a unit spec in RSpec, watch it fail, make it pass.
Do next unit spec likewise.
When Cucumber story passes, feature is complete. Write another story.

Instead of RSpec, is it okay to use Shoulda (with Cucumber, I mean)?
All I see, including in the Rails 3 installation instructions here…
https://github.com/aslakhellesoy/cucumber-rails/blob/master/README.rdoc
… are instructions involving RSpec only. :confused: Bleh.

Should I get acquainted with RSpec?
Actually, can’t Shoulda and RSpec work together?
There’s got to be some down-to-earth tutorial about all this…

undefined method `paginate’ for #Class:0x5eb4ad0"

(SectionsControllerTest):
NoMethodError: undefined method `response_code’ for nil:NilClass

This doesn’t mean anything to me.

How can that not mean anything to you, when it’s telling you exactly
what the error is?

All this error tells me is that something that is nil is trying to
call response_code. The error I get with rails server and browsing to
the page is
undefined method `paginate’ for #Class:0x5eb4ad0" which tells me
that I have to check out the paginate method - something much more
direct/useful!!!

(In my test, I had should
respond_with :success.)

You can step through with the debugger to see where it fails.

Also, RSpec and Cucumber have better error reporting than Test::Unit.

ohhh I hope so.

So from here, I’ll try to get Cucumber working for my functional
tests… Is cucumber ONLY for functionals, or integration/others too?
I have shoulda working for unit tests…

13

On Dec 26, 10:18pm, Marnen Laibow-Koser [email protected] wrote:

All I see, including in the Rails 3 installation instructions here…
https://github.com/aslakhellesoy/cucumber-rails/blob/master/README.rdoc
… are instructions involving RSpec only. :confused: Bleh.

Bleh? What have you got against RSpec.
…

Should I get acquainted with RSpec?
Yes.

haha I guess I’ll have to get acquainted with it…

All this error tells me is that something that is nil is trying to
call response_code.

Exactly! So where are you calling response_code ? Find out why you’ve
got a nil object there.

The error I get with rails server and browsing to
the page is
undefined method `paginate’ for #Class:0x5eb4ad0" which tells me
that I have to check out the paginate method - something much more
direct/useful!!!

There you go, then.

Thing is, nowhere in my application is there a call of response_code!
The error lies in the paginate method - an error revealed by browsing
after doing rails server, NOT by testing! If testing had told me the
paginate method was undefined, I would be satisfied.

In any case… the better error reporting in cucumber/rspec will
hopefully quell these concerns.

I’ll get back to you on how the rspec + cucumber works out. I’ve been
reading the background of cucumber and I’ll get them installed/running
soon… hopefully.

I came across this though: webrat or capybara? I’m not sure which.
Either seems fine? I think I’ll just choose webrat…?

14

daze wrote in post #970911:
[…]

Thing is, nowhere in my application is there a call of response_code!
The error lies in the paginate method - an error revealed by browsing
after doing rails server, NOT by testing! If testing had told me the
paginate method was undefined, I would be satisfied.

Was there a stack trace?

In any case… the better error reporting in cucumber/rspec will
hopefully quell these concerns.

I would think so.

I’ll get back to you on how the rspec + cucumber works out. I’ve been
reading the background of cucumber and I’ll get them installed/running
soon… hopefully.

I came across this though: webrat or capybara? I’m not sure which.
Either seems fine? I think I’ll just choose webrat…?

I’m not sure. I’ve been using Webrat since before Capybara existed. I
think Capybara is supposed to have some advantages over Webrat
(including better JavaScript integration, maybe?), so I might try it on
my next project. Do your research and pick.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

15

daze wrote in post #970823:
[…]

My usual procedure:
Write a Cucumber story for functionality, watch it fail.
Figure out the first thing I need to do to implement that functionality,
write a unit spec in RSpec, watch it fail, make it pass.
Do next unit spec likewise.
When Cucumber story passes, feature is complete. Write another story.

Instead of RSpec, is it okay to use Shoulda (with Cucumber, I mean)?

Probably – if that will even work. I don’t know. Cucumber grew out of
RSpec, so I don’t know how well it works with other test frameworks.
Why don’t you check the docs?

All I see, including in the Rails 3 installation instructions here…
https://github.com/aslakhellesoy/cucumber-rails/blob/master/README.rdoc
… are instructions involving RSpec only. :confused: Bleh.

Bleh? What have you got against RSpec.

Should I get acquainted with RSpec?

Yes.

Actually, can’t Shoulda and RSpec work together?

I think so. But I don’t use Shoulda.

There’s got to be some down-to-earth tutorial about all this…

undefined method `paginate’ for #Class:0x5eb4ad0"

(SectionsControllerTest):
NoMethodError: undefined method `response_code’ for nil:NilClass

This doesn’t mean anything to me.

How can that not mean anything to you, when it’s telling you exactly
what the error is?

All this error tells me is that something that is nil is trying to
call response_code.

Exactly! So where are you calling response_code ? Find out why you’ve
got a nil object there.

The error I get with rails server and browsing to
the page is
undefined method `paginate’ for #Class:0x5eb4ad0" which tells me
that I have to check out the paginate method - something much more
direct/useful!!!

There you go, then.

(In my test, I had should
respond_with :success.)

You can step through with the debugger to see where it fails.

Also, RSpec and Cucumber have better error reporting than Test::Unit.

ohhh I hope so.

So from here, I’ll try to get Cucumber working for my functional
tests… Is cucumber ONLY for functionals, or integration/others too?

Cucumber stories tend to cover the same ground as functional and
integration tests. Again, read the docs.

I have shoulda working for unit tests…

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

16

daze wrote in post #971002:

On Dec 27, 12:37pm, Marnen Laibow-Koser [email protected] wrote:

I’ll get back to you on how the rspec + cucumber works out. I’ve been
reading the background of cucumber and I’ll get them installed/running
soon… hopefully.

[…]

Okay… Cucumber is not something you pick up in a day, is it?

Probably not. For some people, though, it could be.

What’s
the learning curve - as in, how long do you estimate it will take
before I get the hang of this?

I don’t know how your mind works. If you’re working with it daily, I’d
probably estimate 1-2 weeks. Let us know how it goes.

I’m determined to master it… BDD definitely seems like the way to go.

I think it is!

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

17

Can I chip in here as a slight aside - after Marnen (or someone else on
here) “tore a strip off me” after I asked about cucumber without really
doing the groundwork myself I went off and tried it in my app (sorry
about the initial lack of effort and thanks for the kick up the arse).

Anyway to cut a long story short - it’s brilliant, I was up and running
in no time and generated massive test coverage easily, lots of docs/tuts
out there on the wires.

Yes I know that I need to be BDD eventually but for now I have test
coverage that I control and can implement new tests easily. Anyway - I
love it. Long live cucumber.

18

On Dec 27, 12:37pm, Marnen Laibow-Koser [email protected] wrote:

I’ll get back to you on how the rspec + cucumber works out. I’ve been
reading the background of cucumber and I’ll get them installed/running
soon… hopefully.

[…]

Okay… Cucumber is not something you pick up in a day, is it? What’s
the learning curve - as in, how long do you estimate it will take
before I get the hang of this?
I’m determined to master it… BDD definitely seems like the way to go.

19

On Dec 28, 8:52am, Marnen Laibow-Koser [email protected] wrote:

love it. Long live cucumber.
Hey, I’m hoping that going through this rspec book is a good idea?
Pragmatic Bookshelf: By Developers, For Developers

20

bingo bob wrote in post #971015:

Can I chip in here as a slight aside - after Marnen (or someone else on
here) “tore a strip off me” after I asked about cucumber without really
doing the groundwork myself I went off and tried it in my app (sorry
about the initial lack of effort and thanks for the kick up the arse).

Anyway to cut a long story short - it’s brilliant, I was up and running
in no time and generated massive test coverage easily, lots of docs/tuts
out there on the wires.

:slight_smile:

Yes I know that I need to be BDD eventually but for now I have test
coverage that I control and can implement new tests easily.

You’ve been saying this for months. Stop procrastinating and do it.

Anyway - I
love it. Long live cucumber.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone