Well, you are testing your controller here and probably your controller IS
fine, if I had to guess (as is your controller test). The old RSpec “request”
tests are now “feature” test and those are the more-full-stack-ish tests that
would most likely show the errors you encounter in the browser.
Put the capybara gem in the :test stanza of your Gemfile, then create the
/spec/features directory. You can then make, for example, a spec like:
require 'spec_helper'
feature "Homepage" do
context "Not logged in" do
scenario "Correct elements should be visible on homepage" do
visit root_path
page.should have_content "Create an account"
page.should_not have_selector("#adwords-signup-conversion-js")
page.should_not have_selector("#facebook-signup-conversion-js")
end
end
end
This is just an example, but probably your error requires the view to actually
render, and it’s a test like this that will do that.
AB
On Jan 11, 2014, at 10:53 AM, Chris McCann <[email protected]> wrote:
> SD Ruby,
>
> Over the holidays I embarked on a long-needed upgrade of the first Rails app
> I built, taking it from 2.3 to 3.1. I plan to move it to 4.0 by the time I'm
> done.
>
> Since this app was created over 6 years ago, before I understood the value of
> having test coverage, it has very little. I've been remedying that via RSpec
> (2.14) and FactoryGirl and I'm pleased with the progress I've made and even
> discovered some bugs that weren't apparent pre-test.
>
> The app is rather large and I need to get this upgrade done quickly since my
> customers are clamoring for more features. I'm trying to balance basic
> "sanity checking" test coverage with the need for speed.
>
> I use simple_navigation to provide the links between the main menus and
> controller actions. I thought it would be worthwhile to gin-up a bunch of
> request specs for the URLs that the menu links hit. It seemed to me I'd at
> least have a basic "does the page for that menu link blow up?" scenario as a
> rudimentary check of the app. But that doesn't seem to work the way I
> expected.
>
> For example, hitting a URL via a request spec and checking for a 200 status
> passes. But if I go to that same page in the browser I find vestiges of
> rails 2.3 that have been removed, like "error_messages_for" and the page
> throws an error.
>
> So I'm getting a false positive on the request spec -- how come? Perhaps my
> understanding of what a request spec provides is flawed but I assumed an
> error in the page wouldn't allow the spec to pass.
>
> My next attempt was to create controller specs for the controllers hit by the
> menus. I use a before_filter in application_controller to set the current
> chapter and in trying to check that value is assigned isn't working.
>
> In the snippet below MemberController < ApplicationController. The expect
> fails because the assigns(:chapter) returns nil.
>
> require 'spec_helper'
>
> describe MemberController do
> before :each do
> @chapter = FactoryGirl.create(:chapter)
> controller.stub!(:current_chapter).and_return(@chapter)
> end
>
> describe "GET my_home" do
> it "assigns @chapter" do
> get :my_home
> expect(assigns(:chapter)).to eq @chapter
> end
> end
> end
>
> I'm a n00bie with RSpec so perhaps my understanding is flawed. How should
> this be setup? Is there a better way?
>
> Thanks,
>
> Chris
>
> --
> --
> SD Ruby mailing list
> [email protected]
> http://groups.google.com/group/sdruby
> ---
> You received this message because you are subscribed to the Google Groups "SD
> Ruby" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
--
--
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
---
You received this message because you are subscribed to the Google Groups "SD
Ruby" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
