Remove controllers references from API request specs

[kennyadsl]

A while ago, we converted API controller specs into requests specs, see #2052. But those specs still have references from their old "life" that we can clean a little bit with a small effort.

In fact, their filenames still have the _controller_ part, which makes no sense now. Eg. solidus/api/spec/requests/spree/api/addresses_controller_spec.rb

Also, they contain references to the previous class tested as the described class. Eg.

module Spree
  describe Api::AddressesController, type: :request do
  # ...

Let's clean them!

[niamtokik]

Hi,

I would like to help. I am looking for a Ruby project to improve my level in this language. Seems a good issue to start.

In fact, their filenames still have the _controller_ part, which makes no sense now. Eg. solidus/api/spec/requests/spree/api/addresses_controller_spec.rb

Those files should now be renamed like solidus/api/spec/requests/spree/api/addresses_request_spec.rb, so, replacing controller by request? Or _controller_ term should just be removed?

Also, they contain references to the previous class tested as the described class. Eg.

If I take your example, module Spree should look like that after the cleanup:

module Spree
  describe Api::AddressesRequest, type: :request do
  # ...

Other dependencies in the code should be in this case modified too, right?

[jarednorman]

The code after your cleanup wouldn't work, as that constant doesn't exist.

@kennyadsl Do you have any thoughts on what the convention should be for those top-level describes in request specs?

[kennyadsl]

@niamtokik @jarednorman I didn't have anything in mind. I think we can do some research and apply the current best practices in the Rails ecosystem.

[tejasbubane]

I stubled upon this issue while looking for some beginner-level issues. I think this is resolved by #4158 and can be closed now?

[kennyadsl]

You are right, thanks!