Consider making example group mixins more explicit

[myronmarston]

There's a lot of implicit file-location-based configuration done by rspec-rails--e.g. spec files in "spec/{models/controllers/requests/mailers/etc}" get a special mixin just by being in that directory. This fits well with rails' "convention over configuration" philosophy, but often creates confusion, as it's not obvious from looking at the code where particular helper methods are coming from. In addition, this setup can actively get in your way if you decide that you want to use a different directory structure. For example, @xaviershay blogged about the way he tests rails apps, and he uses a top level unit/integration/acceptance directory structure. I haven't worked on a rails app in a while, but I've been using kind of top-level structure in my ruby applications as well, and I'd probably use it the next time I build a rails app.

For rspec-rails, I was thinking we could make things a bit more explicit:

• By default, don't mixin the various example group modules based on file location.
• Use simple, explicit metadata tagging to mixin example groups instead (e.g. describe User, :model do... or describe UsersController, :controller do...). This is the same mechanism that shared contexts can use, and in fact, the existing mixins could easily be rewritten as shared contexts (which would decouple them from ActiveSupport::Concern).
• Provide a config option so that users who want to use the file-location mechanism still can, e.g. RSpec.configuration.infer_spec_type_from_file_location = true.
• The generated spec_helper.rb file could include this config line by default, with a comment explaining it--that would keep the current behavior the same for new apps.
• If we move in this direction, we'll probably want to provide the config option in the last 2.x release, and maybe have it generate a warning if it's not set (so that users can use that release to help get their apps ready to upgrade, then upgrade to rspec-rails 3 and have it work).

[mehulkar]

👍

Or maybe the ability to write a top level yaml file that defines what our directory structure looks like? I'm returning to rspec after a year and I'm having trouble figuring out exactly what methods are available where.

I don't think this makes anything more transparent in terms of seeing what modules are mixed in or what modules are available but I'm fan of not enforcing a directory layout on people.

[xaviershay]

Obviously I am in favour of this :) I've always found the magic directories confusing, even before I started doing it my own way.

[cupakromer]

👉 (mixed on this one)

I personally, just my 2¢, really like the auto-inferring based on the file path. This very much falls in line with the Rails convention over configuration. Rails has specific locations for code, it just makes sense that the tests mirror that (to a degree). It also makes sense that the related type of tests auto-includes the relevant setup (yes I realize that MiniTest and Rails force class inheritance and don't mix stuff in magically).

IMHO, I think RSpec.configuration.infer_spec_type_from_file_location should default to true. The comment added should then instead state set it to false (or add uncomment the following line, which sets false) - opt-out not in. It is always a bit frustrating to have long time explicit convention defaults reversed.

With that said, there are times I do want to customize it. Having looked at the code, I know how to do this (see setup file). Though, duplicating those lines for different file paths is not a fun approach. It would be great to see:

• The ability to add directories to these defaults. Maybe something like: RSpec.configuration.integration_specs_path << "acceptance"?
• Better Relish/Readme documentation stating the metadata required for each spec type
• Better Relish/Readme documentation stating how to customize the different spec paths

❤️

[chris-teague]

RSpec.configuration.integration_specs_path << "acceptance" etc included in config out the box feels like a nice layer of visibility for those wanting to break from the norm.

[DanielHeath]

What about RSpec.configuration.auto_mixins["models"] = ReplacementModelMixin?

Maintain the existing magic whilst making overriding/reconfiguring easy.

[todd]

I can go either way on this one, but I think providing this as a configuration option instead of the default might be a better path to go down. Just my $0.02.

Either way, I think it's worth implementing in some form.

[cupakromer]

I'll take a stab at adding the [current version of the] docs I proposed tomorrow ❤️ ❤️

[fatgeekuk]

possibly interesting, but how about infering the mixin from the class of the top level describe subject.

So if it is a kind_of? ActiveRecord::Base, it gets the models, if a Controller it gets them. thats ok I suppose for Model and Controller mixings, but when you get to Request... hmmm, then fall back to explicitly mentioning again, and allow explicit for when you have a bare Object subclass as a model...

[jimmycuadra]

Great idea. I don't see this as being the standard use case for most Rails developers, so I agree that it should remain the way it is now with a configuration option to disable the auto-mixins. However, adding it as a configuration option in the generated spec_helper.rb implies that the intent is to eventually change the default, which I don't think is a good idea. This is a situation where the Rails-ism of "sensible defaults with a way to choose something else if you really want to" applies perfectly. I would suggest having the option set to true by default, and developers who want more control can explicitly set it to false.

[dchelimsky]

rspec-rails uses public APIs from rspec-core to do this auto-inclusion. There is one additional helper in that file, which is there to support windows and *nix paths. We could probably clarify that helper a bit and expose it as an API, but I don't think we need to expose any new API on Configuration beyond the infer_spec_type_from_file_locationoption which, IMO, should default to true for rspec-rails-3 and only default to false in rspec-rails-4 or later if community pushes it that way.

[tadast]

I personally never had a need to change the inferred defaults and think that making it explicit would be a step back. Overridible defaults > configuration.

[dasch]

👍 it will make it easier to avoid getting the Active Record stuff mixed into specs of non-AR models.