Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Consistent request spec naming #2356

Closed
wants to merge 3 commits into from
Closed

Consistent request spec naming #2356

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d3ab909
Use consistent naming for request specs
eloyesp Jun 17, 2020
6cffc05
Reuse request spec generator shared examples
eloyesp Jun 17, 2020
c6f72ac
Fix example app generators conflicting files
eloyesp Jun 18, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 1 addition & 1 deletion example_app_generator/generate_stuff.rb
View file
Open in desktop
Expand Up @@ -84,8 +84,8 @@ def using_source_path(path)
generate('rspec:install')
generate('controller wombats index') # plural
generate('controller welcome index') # singular
generate('rspec:request wombats')
generate('integration_test widgets')
generate('rspec:request widgets')
generate('mailer Notifications signup')

generate('model thing name:string')
Expand Down
7 changes: 5 additions & 2 deletions lib/generators/rspec/controller/controller_generator.rb
View file
Open in desktop
Expand Up @@ -4,6 +4,8 @@ module Rspec
module Generators
# @private
class ControllerGenerator < Base
source_paths << File.expand_path('../integration/templates', __dir__)

argument :actions, type: :array, default: [], banner: "action action"

class_option :template_engine, desc: "Template engine to generate view files"
Expand All @@ -15,8 +17,9 @@ class ControllerGenerator < Base
def generate_request_spec
return unless options[:request_specs]

template 'request_spec.rb',
File.join('spec/requests', class_path, "#{file_name}_request_spec.rb")
template_file = actions.empty? ? 'request_spec.rb' : 'request_with_actions_spec.rb'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You've renamed the file so where does the alternate come from? Any differences are also untested which I'd like to see rectified!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You've renamed the file so where does the alternate come from?

The alternate template comes from the integration generator (added on the source_paths on line 7).

Any differences are also untested which I'd like to see rectified!

It is reusing functionality of requests generator (and integration generator) because it is just re-using the template, but it is actually being tested on the shared example.

Testing with that shared example we make sure that generators that generate request specs does use a consistent format (they all pass the same specs) while differences between specs are being also being tested.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe generate posts with a scaffold, and generate books with controller generator?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You haven't added a test for the different behaviour, and there is different behaviour now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JonRowe I did add a shared example that it's testing just that new behavior. You can check that removing that code and specs will fail with meaningful errors.

The specs for that code are in this support file. I'm just adding one line of test because I'm reusing existing specs.

Does it makes sense?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JonRowe Runing the tests without the implementation changes gives those rspec failures.

template template_file,
File.join('spec/requests', class_path, "#{file_name}_spec.rb")
end

def generate_controller_spec
Expand Down
0 ...spec/controller/templates/request_spec.rb → ...er/templates/request_with_actions_spec.rb
View file
Open in desktop
File renamed without changes.
5 changes: 3 additions & 2 deletions spec/generators/rspec/controller/controller_generator_spec.rb
View file
Open in desktop
Expand Up @@ -4,9 +4,10 @@

RSpec.describe Rspec::Generators::ControllerGenerator, type: :generator do
setup_default_destination
it_behaves_like "a request spec generator"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a bit unsure about including this here. What was the goal of it?

Because a couple of tests in that shared example are already in controller_generator_spec so the same things are tested twice.

It appears to me that originally purpose of the example sharing was that integration_test and rspec:request behave exactly the same way

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see the other discussion now.... Not to crush your spirit here, but may I suggest to split the two behaviour changes (file naming & content of ControllerGenerator? The ControllerGenerator and the Request/Integration Generator are not the same thing.
There is no inheritance or module connection at all, sometimes repetition in tests is a good thing for understandability

ControllerGenerator executes also the rails generators, while the RequestGenerator only generates the test files (for example to test already existing untested controllers in a codebase)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ControllerGenerator and the Request/Integration Generator are not the same thing.

My idea here is not make them the same thing, but enforce them to behave as a "request generator". That way, given a certain configuration we can expect them to generate the same request specs.

There is no inheritance or module connection at all, sometimes repetition in tests is a good thing for understandability.

In the case of the controller generator, there is no inheritance, but they share the same template file.

I prefer to use the shared example instead of repeat test, because I like the idea of make sure that this compatibility is maintained in new versions, so the file naming convention becomes a specification for requests generators.


describe 'request specs' do
subject { file('spec/requests/posts_request_spec.rb') }
subject { file('spec/requests/posts_spec.rb') }

describe 'generated by default' do
before do
Expand Down Expand Up @@ -38,7 +39,7 @@
end

describe 'with namespace and actions' do
subject { file('spec/requests/admin/external/users_request_spec.rb') }
subject { file('spec/requests/admin/external/users_spec.rb') }

before do
run_generator %w[admin::external::users index custom_action]
Expand Down