Fixes requests specs generated by scaffold with namespace resource

[PedroAugustoRamalhoDuarte]

Description

Refactor show_helper to match variable spec data in requests specs created by scaffold generators, when the resource has a namespace

Example generator response

rails g scaffold accounts/user name:string

require 'rails_helper'

# This spec was generated by rspec-rails when you ran the scaffold generator.
# It demonstrates how one might use RSpec to test the controller code that
# was generated by Rails when you ran the scaffold generator.
#
# It assumes that the implementation code is generated by the rails scaffold
# generator. If you are using any extension libraries to generate different
# controller code, this generated spec may or may not pass.
#
# It only uses APIs available in rails and/or rspec-rails. There are a number
# of tools you can use to make these specs even more expressive, but we're
# sticking to rails and rspec-rails APIs to keep things simple and stable.

RSpec.describe "/accounts/users", type: :request do
  # This should return the minimal set of attributes required to create a valid
  # Accounts::User. As you add validations to Accounts::User, 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 headers
  # in order to pass any filters (e.g. authentication) defined in
  # Accounts::UsersController, or in your router and rack
  # middleware. Be sure to keep this updated too.
  let(:valid_headers) {
    {}
  }

  describe "GET /index" do
    it "renders a successful response" do
      Accounts::User.create! valid_attributes
      get accounts_users_url, headers: valid_headers, as: :json
      expect(response).to be_successful
    end
  end

  describe "GET /show" do
    it "renders a successful response" do
      user = Accounts::User.create! valid_attributes
      get accounts_user_url(user), as: :json
      expect(response).to be_successful
    end
  end

  describe "POST /create" do
    context "with valid parameters" do
      it "creates a new Accounts::User" do
        expect {
          post accounts_users_url,
               params: { accounts_user: valid_attributes }, headers: valid_headers, as: :json
        }.to change(Accounts::User, :count).by(1)
      end

      it "renders a JSON response with the new accounts_user" do
        post accounts_users_url,
             params: { accounts_user: valid_attributes }, headers: valid_headers, as: :json
        expect(response).to have_http_status(:created)
        expect(response.content_type).to match(a_string_including("application/json"))
      end
    end

    context "with invalid parameters" do
      it "does not create a new Accounts::User" do
        expect {
          post accounts_users_url,
               params: { accounts_user: invalid_attributes }, as: :json
        }.to change(Accounts::User, :count).by(0)
      end

      it "renders a JSON response with errors for the new accounts_user" do
        post accounts_users_url,
             params: { accounts_user: invalid_attributes }, headers: valid_headers, as: :json
        expect(response).to have_http_status(:unprocessable_entity)
        expect(response.content_type).to match(a_string_including("application/json"))
      end
    end
  end

  describe "PATCH /update" do
    context "with valid parameters" do
      let(:new_attributes) {
        skip("Add a hash of attributes valid for your model")
      }

      it "updates the requested accounts_user" do
        user = Accounts::User.create! valid_attributes
        patch accounts_user_url(user),
              params: { accounts_user: new_attributes }, headers: valid_headers, as: :json
        user.reload
        skip("Add assertions for updated state")
      end

      it "renders a JSON response with the accounts_user" do
        user = Accounts::User.create! valid_attributes
        patch accounts_user_url(user),
              params: { accounts_user: new_attributes }, headers: valid_headers, as: :json
        expect(response).to have_http_status(:ok)
        expect(response.content_type).to match(a_string_including("application/json"))
      end
    end

    context "with invalid parameters" do
      it "renders a JSON response with errors for the accounts_user" do
        user = Accounts::User.create! valid_attributes
        patch accounts_user_url(user),
              params: { accounts_user: invalid_attributes }, headers: valid_headers, as: :json
        expect(response).to have_http_status(:unprocessable_entity)
        expect(response.content_type).to match(a_string_including("application/json"))
      end
    end
  end

  describe "DELETE /destroy" do
    it "destroys the requested accounts_user" do
      user = Accounts::User.create! valid_attributes
      expect {
        delete accounts_user_url(user), headers: valid_headers, as: :json
      }.to change(Accounts::User, :count).by(-1)
    end
  end
end

Issues

closes #2491

[JonRowe]

I think this makes sense, @pirj / @benoittgt can either of you cast an eye over this?

[pirj]

But why?

      accounts_user = Accounts::User.create! valid_attributes
      get accounts_user_url(accounts_user), as: :json

It makes it clear what namespace a certain model belongs to.
Accounting::User and Reader::User might be quite different.

If RSpec is used as a project documentation tool, I'd prefer it to be more specific by default.

What do you think?

[PedroAugustoRamalhoDuarte]

Before my changes the generator output was:

# Output
user = Accounts::User.create! valid_attributes
get accounts_user_url(accounts_user), as: :json

# Source
# <%= file_name #>  returns 'user'
<%= file_name %> = <%= class_name %>.create! valid_attributes
get <%= show_helper %>, as: :json

To keep the pattern from another templates, example controller_spec ,i have use the file_name to be argument from path. In my pratice i use more the small name like user, but thinking as project documentation tool is better keep the full_name from resource, do you like that i change all file_name calls from generator source to be ns_file_name?

[pirj]

@JonRowe @benoittgt What do you guys think? accounts_user or just user for Accounts::User?

[JonRowe]

They should be the same and the spec should work either way? e.g. I think this report is that one is user and one is accounts_user and thats wrong?

[PedroAugustoRamalhoDuarte]

Yes. I explained the problem with more details in this issue #2491 . We can fix the spec generator to use accounts_user or just user, in my PR, I chose user.
In order to change to accounts_user and keep the pattern from another templates generators, we need to change some other lines.

[PedroAugustoRamalhoDuarte]

@pirj did you guys make a choice?

[pirj]

Tested on a newly-created app, works fine.

Thanks for your contribution, @PedroAugustoRamalhoDuarte, and please accept my apologies for the confusion regarding the requirements and the delayed response.