-
-
Notifications
You must be signed in to change notification settings - Fork 1k
Update fixture support #1372
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
Update fixture support #1372
Conversation
e145598
to
7db0a53
Compare
Looks sane to me |
# | ||
# @deprecated Include `RSpec::Rails::RailsExampleGroup` or | ||
# `RSpec::Rails::FixtureSupport` directly instead | ||
config.include RSpec::Rails::FixtureSupport |
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.
What does it mean to tag a line of code as deprecated rather than a method or class? Will users see this deprecation in the YARD docs? And why are you including the module above and here?
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.
It was mostly a note for myself and others for 3.99. Line 72 is us globally patching fixture support onto all specs. Due to semver we can't just remove it. So this was a reminder that we need to warn users in 3.99.
I've added fixture support to the RSpec::Rails:RailsExampleGroup
base module. So all Rails related specs which people expect fixtures to be available for will have it. Line 63 above provides an option for people to selectively include fixture support onto any example/group via metadata.
9fb9b69
to
9af397a
Compare
This fixes an "undefined method `fixture_path`" error caused in `RSpec::Core::Configuration`. The issue occurs when a spec is created before rspec-rails is loaded. The cause is rspec-core attempts to include the `RSpec::Rails::FixtureSupport` module into the existing spec as soon as we tell the configuration about it, but have not told the configuration about the new related options. This moves the including of the module until after we have told the configuration about the dependent options. This includes a spec which is named in a manner to attempt to ensure it is the first spec loaded by rspec-core; which loads spec files alphabetically. To ensure we test the issue the run script is updated to also run this spec file standalone. When discussing #1355 it was agreed that we need to consider removing this global inclusion of the fixture support. Instead favoring including it in the `RailsExampleGroup`. A deprecation comment has been included to remind us later.
This changes to nearly mirrors how the configuration is tested in rspec-core. Instead of setting up a new configuration object each test run, we clone the existing object. This does two things: - prevents polluting the actual test configuration - instead of creating a new configuration it clones the existing one to ensure we actually modify the RSpec config
These specs are in a more integration style; instead of a more unit-collaborator approach which would simply ensure that the proper messages were sent to the configuration object. The reason is that users of rspec-rails have specific expectations on how the configuration options are available. If rspec-core changes anything related to these calls that will break the rspec-rails user's expectations. To ensure that doesn't happen we are fully testing the integration between our shim and the `RSpec.configuration`.
This adds metadata to ad-hoc include fixture support for any examples or groups which may require it. It additionally, includes fixture support into all default `RailsExampleGroup` modules. This provides the current functionality for the majority of use cases.
9af397a
to
278972d
Compare
[ci skip]
How do I globally disable RSpec::Rails::FixtureSupport? |
@mnoack if this is presenting as an actual issue for you that broke compatibility, please open a new issue. We'd prefer it if you not comment on old issues. If you do open your issue, can you please provide clear steps to reproduce, following this guide:
|
Hacky backport of rspec/rspec-rails#1372 to avoid having to update to rspec 3+, which we are not compatible with.
This fixes an "undefined method
fixture_path
" error caused inRSpec::Core::Configuration
. The issue occurs when a spec is createdbefore rspec-rails is loaded. The root cause is rspec-core attempts to
include the
RSpec::Rails::FixtureSupport
module into the existing specas soon as we tell the configuration about it, but have not told the
configuration about the new related options.
This moves the including of the module until after we have told the
configuration about the dependent options.
In order to test this, a custom spec and script are included which
attempt to ensure it is the first spec loaded by rspec-core. To ensure
we test the issue the run script is updated to also run this spec file
standalone.
This also includes full spec coverage for all rspec-rails configuration
options. These specs are written in an integration style; instead of a
more unit-collaborator approach. The reason is that users of rspec-rails
have specific expectations on how the configuration options are
available. If rspec-core changes anything related to these calls which
would break the rspec-rails user's expectations, these specs will catch
it.
This also adds metadata to ad-hoc include fixture support for any
examples or groups which may require it. It additionally, includes
fixture support into all default
RailsExampleGroup
modules. Thisprovides the current functionality for the majority of use cases.
Fix #1355