-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Make filetype infer opt-in #970
Conversation
# You can disable this behaviour by removing the line below, and instead | ||
# explictly tag your specs with their type, e.g.: | ||
# | ||
# describe UsersController, :controller do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this metadata be :type => :controller
? :controller
is just the short form for :controller => true
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh whoops, yeah.
👍 I'm a fan of this. I think that making it opt-in with the generated file turning it on is the right approach to take. |
Hmm...one thought though: if we move towards having separate |
So I just started using the other PR we merged ( We probably want to hold off this PR until it's more comprehensive (i.e. allows explicit configuration of directories maybe?) |
Personally. I feel we should remove filetype inferring and update the generators to set the specific tags rather than dealing with this. We can obviously only do this at major versions like this, but it would be beneficial to the Rails testing community. |
So after getting that other PR in, I'm feeling zero inclination to work on this. I don't think it should be merged as is (even after addressing local feedback), not useful enough. |
Personally, I'm not a fan of completely removing the filetype inferring. I agree it can be confusing for people first encountering it. Though I'm not sure forcing metadata tags makes that any less magical; it feels like swapping one magic convention for another. I can see the flexibility/freedom it will allow with spec organization; though I'm not entirely convinced that's all good. My other major concern is large existing projects which wish to upgrade to RSpec 3. Without either a tool to automatically tag all of the existing specs, or a way to opt-in to the well established behavior, upgrading will be come a much more time consuming task. |
Transpec would surely be able to upgrade the specs, it's not a hard identification task. I completely disagree that tagging them is as magic as inferring from directory structure. The former is explicit the later is completely hidden from the developer, note that Rails does not force folder conventions on developers (you can happily have active_record models in |
After sleeping on it, I agree that metadata is less magical. When I first used RSpec, metadata was something that never came up. So as I first started hearing about it, and saw it for the first time, it seemed a bit magical. At the time, "just add this tag" and "put the spec file there" held the same level of "magic under the hood". This feeling was compounded when the metadata definitions were in a gem. I agree that having transpec upgrade the specs will go a very long way. Also, I think most of my concerns at this point are simply resolved by updating the docs explaining the different ways to mark a spec. I'm happy to work on the doc changes. |
I'm looking at this again. |
Addressed comments. Completely removing file type inferring is too drastic a step without at least going through an opt-in period first, because it would break basically every tutorial on the internet. We should consider it for 4 though, if opt-out becomes popular. |
I completely agree. Anyhow, this LGTM. I think we need a deprecation warning in 2.99 instructing people to add the new config setting (and the setting API should be backported but be a no-op). Also, with this in place does it still make sense to have the |
If this works I think we should |
I'm going to merge this since I'm happy with it and the thing I'm working on (which resolves rspec/rspec-core#1089 / #829 / rspec/rspec-core#969 all in one pretty simple change) will build off of this. |
Make filetype infer opt-in
- In #970 we added `infer_spec_type_from_file_location!` but forgot to remove the code in `lib/rspec/rails/configuration.rb` that made it always infer - so the opt-in API was there but it was always enabled. Here I've made it truly opt-in. - The logic of `infer_spec_type_from_file_location!` also setup the helper module inclusion via explicit `:type` metadata but was only intended to setup the implicit mapping of spec file location to type. Here I've made the module inclusion via `:type` always work w/o an explicit config option needed to enable it. - We used to mutate the `:type` metadata on inclusion of the helper module, but this caused bugs such as #825. The problem is that rspec-core uses a raw hash for the metadata and doesn't re-apply filtering/inclusion logic when the metadata hash is mutated. Instead, we use a new explicit `define_derived_metadata` API. Fixes #825 and closes #829.
- In #970 we added `infer_spec_type_from_file_location!` but forgot to remove the code in `lib/rspec/rails/configuration.rb` that made it always infer - so the opt-in API was there but it was always enabled. Here I've made it truly opt-in. - The logic of `infer_spec_type_from_file_location!` also setup the helper module inclusion via explicit `:type` metadata but was only intended to setup the implicit mapping of spec file location to type. Here I've made the module inclusion via `:type` always work w/o an explicit config option needed to enable it. - We used to mutate the `:type` metadata on inclusion of the helper module, but this caused bugs such as #825. The problem is that rspec-core uses a raw hash for the metadata and doesn't re-apply filtering/inclusion logic when the metadata hash is mutated. Instead, we use a new explicit `define_derived_metadata` API. Fixes #825 and closes #829.
(Re-issue of #967 against master)
Begins to address #662
spec_helper.rb
will opt-in, with an explanatory comment.DO NOT MERGE: Needs a 2.99 deprecation.
@alindeman @myronmarston