Skip to content

Remove non-Rails-5 features from controller spec scaffold #1689

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Aug 10, 2016
Merged

Remove non-Rails-5 features from controller spec scaffold #1689

merged 3 commits into from
Aug 10, 2016

Conversation

CodingItWrong
Copy link
Contributor

Fixes #1605 by removing all expectations for assigns and templates rendered from the controller specs generated for scaffolds. Sample generated spec below.

They feel a big lethargic because all that’s being specified for a lot of the methods now is only that they return HTTP success—but I believe that’s all there is to specify for them in a vanilla Rails 5 install.

A few other things we could consider:

  • Generating commented out “assigns” and “template rendered” expectations, along with a comment explaining the rails-controller-testing gem.
  • Detecting whether “assigns” and “template rendered” expectations are available (i.e. a Rails 4 app, or a Rails 5 app with the rails-controller-testing gem), and generating the appropriate expectations then. That would significantly increase the complexity of the controller spec template.

Happy to take this PR any direction y’all would like—let me know how I can help!

Here’s a sample of the generated spec, which passes once I take care of the skips:

require 'rails_helper'

# (header comments trimmed)

RSpec.describe PostsController, type: :controller do

  # This should return the minimal set of attributes required to create a valid
  # Post. As you add validations to Post, be sure to
  # adjust the attributes here as well.
  let(:valid_attributes) {
    skip("Add a hash of attributes valid for your model")
  }

  let(:invalid_attributes) {
    skip("Add a hash of attributes invalid for your model")
  }

  # This should return the minimal set of values that should be in the session
  # in order to pass any filters (e.g. authentication) defined in
  # PostsController. Be sure to keep this updated too.
  let(:valid_session) { {} }

  describe "GET #index" do
    it "returns a success response" do
      post = Post.create! valid_attributes
      get :index, params: {}, session: valid_session
      expect(response).to be_success
    end
  end

  describe "GET #show" do
    it "returns a success response" do
      post = Post.create! valid_attributes
      get :show, params: {id: post.to_param}, session: valid_session
      expect(response).to be_success
    end
  end

  describe "GET #new" do
    it "returns a success response" do
      get :new, params: {}, session: valid_session
      expect(response).to be_success
    end
  end

  describe "GET #edit" do
    it "returns a success response" do
      post = Post.create! valid_attributes
      get :edit, params: {id: post.to_param}, session: valid_session
      expect(response).to be_success
    end
  end

  describe "POST #create" do
    context "with valid params" do
      it "creates a new Post" do
        expect {
          post :create, params: {post: valid_attributes}, session: valid_session
        }.to change(Post, :count).by(1)
      end

      it "redirects to the created post" do
        post :create, params: {post: valid_attributes}, session: valid_session
        expect(response).to redirect_to(Post.last)
      end
    end

    context "with invalid params" do
      it "returns a success response (i.e. to display the 'new' template)" do
        post :create, params: {post: invalid_attributes}, session: valid_session
        expect(response).to be_success
      end
    end
  end

  describe "PUT #update" do
    context "with valid params" do
      let(:new_attributes) {
        skip("Add a hash of attributes valid for your model")
      }

      it "updates the requested post" do
        post = Post.create! valid_attributes
        put :update, params: {id: post.to_param, post: new_attributes}, session: valid_session
        post.reload
        skip("Add assertions for updated state")
      end

      it "redirects to the post" do
        post = Post.create! valid_attributes
        put :update, params: {id: post.to_param, post: valid_attributes}, session: valid_session
        expect(response).to redirect_to(post)
      end
    end

    context "with invalid params" do
      it "returns a success response (i.e. to display the 'edit' template)" do
        post = Post.create! valid_attributes
        put :update, params: {id: post.to_param, post: invalid_attributes}, session: valid_session
        expect(response).to be_success
      end
    end
  end

  describe "DELETE #destroy" do
    it "destroys the requested post" do
      post = Post.create! valid_attributes
      expect {
        delete :destroy, params: {id: post.to_param}, session: valid_session
      }.to change(Post, :count).by(-1)
    end

    it "redirects to the posts list" do
      post = Post.create! valid_attributes
      delete :destroy, params: {id: post.to_param}, session: valid_session
      expect(response).to redirect_to(posts_url)
    end
  end

end

Josh Justice added 3 commits August 9, 2016 04:31
Because many methods only have expectations against variables assigned, nothing is currently specified that can be checked in Rails 5, where assigns checking is not included. This commit adds an expectation of the HTTP response code for each method, unless a redirect is specified (which is implicitly a 301 or 302).
This removes all expectations for assigns and templates rendered. These fail under a vanilla Rails 5 installation because they've been extracted into the `rails-controller-testing` gem.
@JonRowe
Copy link
Member

JonRowe commented Aug 9, 2016

/cc @samphippen

@fables-tales
Copy link
Member

LGTM

@fables-tales fables-tales merged commit 540445c into rspec:master Aug 10, 2016
fables-tales pushed a commit that referenced this pull request Aug 10, 2016
sebjacobs pushed a commit to futurelearn/rspec-rails that referenced this pull request Mar 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants