Rspec test fails

[Jussi Hirvi]

Ok, now I have to ask. I am doing exercise 9.9 from the RoR tutorial (3.2). 

I have this rspec/capybara test to make sure that admin user cannot delete him/herself: 

  subject { page }

  . . .

  describe "as admin user" do

      let(:admin) { FactoryGirl.create(:admin) }

      before { sign_in admin }

      describe "submitting a DELETE request to the Users#destroy action" do

        before { delete user_path(admin) }

        specify { response.should redirect_to(root_path) }

        # cannot get the following test to work, even though in browser it works

        # it { should have_selector('div.alert.alert-error') }

      end

    end

 

The test works otherwise ok, but the commented-out line fails when it shouldn't. I verified in browser that the flash error message does in fact appear - here is the html (hope the html entities for greater-than and less-than will be parsed in the following):  

    <div class="alert alert-error">Admin cannot destroy him/herself.</div>

 

Does this have to do with the fact that the server response involves redirect? How could this be fixed? I can live without this test, but I may need the info later. 

- Jussi

[Gintautas Šimkus]

Redirect ends current request and starts a new one, so you are right that that's the case (another action isn't called nor its template rendered). But shouldn't you also test that admin user is still there (wasn't deleted) after redirect happened? You could have very easily have him deleted in your actual code and still redirect to root_path, making this spec pass incorrectly.

2013/3/28 Jussi Hirvi <jush...@gmail.com>

- Jussi

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-talk/-/k7HUBM1FF8cJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jussi Hirvi]

On Thursday, March 28, 2013 4:06:09 PM UTC+2, Dihital wrote:

Redirect ends current request and starts a new one, so you are right that that's the case (another action isn't called nor its template rendered).

That left me pondering, why does it matter that a new request is started. Anyway, it seems that rspec tests can verify that a redirect to a given path occurs, but there is no way to evaluate the contents of the resulting page: 

http://stackoverflow.com/questions/2865378/rspec-rails-how-to-follow-a-redirect

Maybe someone can verify that this is the case, or tell me otherwise? 

 

But shouldn't you also test that admin user is still there (wasn't deleted) after redirect happened? You could have very easily have him deleted in your actual code and still redirect to root_path, making this spec pass incorrectly.

 

A good idea, yes, but that I left for the future. 

- Jussi

[Frederick Cheung]

On Friday, March 29, 2013 7:32:36 AM UTC, Jussi Hirvi wrote:

On Thursday, March 28, 2013 4:06:09 PM UTC+2, Dihital wrote:

Redirect ends current request and starts a new one, so you are right that that's the case (another action isn't called nor its template rendered).

That left me pondering, why does it matter that a new request is started. Anyway, it seems that rspec tests can verify that a redirect to a given path occurs, but there is no way to evaluate the contents of the resulting page: 

http://stackoverflow.com/questions/2865378/rspec-rails-how-to-follow-a-redirect

Maybe someone can verify that this is the case, or tell me otherwise? 

 

That sounds like they're talking about rspec controller specs (which are designed to spec a single request to a controller) rather than rspec request specs which are designed to do a series of requests (and which I'm not sure existed back in 2010).

Make sure that you are actually doing a request spec (is the file in /spec/requests), and as some of the answers on that page mention, automatic redirect following differs across capybara drivers.

Fred