There were a few changes needed:
* Plugins are now specified through `plugin:` config keyword.
* All plugin gems need to be specified explicitly in Gemfile since they
are no longer dependencies of plugins already specified explicitly.
* All plugin gems need to be updated in other to use the new APIs.
* One cop was renamed.
* New offenses safe to correct were corrected directly with `bundle exec
rubocop -a`.
* New offenses unsafe to correct were added to the TODO configuration
with `bundle exec rubocop --auto-gen-config --auto-gen-only-exclude
--exclude-limit 1400 --no-auto-gen-timestamp`.
If I regenerate the VCR cassetes for
spec/lib/stripe/payment_intent_validator_spec.rb, I get a lot of errors
like this:
```
Stripe::CardError:
Sending credit card numbers directly to the Stripe API is generally
unsafe. We suggest you use test tokens that map to the test card you are
using, see https://stripe.com/docs/testing. To enable testing raw card
data APIs, see
https://support.stripe.com/questions/enabling-access-to-raw-card-data-apis.
```
It seems the sandbox environment associated to my developer API keys is
not allowed to send raw credit card data.
Instead of requesting Stripe support to enable that, or regenerate
cassettes with the API keys in Bitwarden, I figured we could migrate the
tests to not use raw credit card data.
Previous error is fixed, which allows the spec to proceed further, and
reveals that the current cassettes are missing some requests:
```
1) Stripe::PaymentIntentValidator#call as a guest when payment intent is valid valid non-3D credit cards are correctly handled behaves like payments intents from Visa returns payment intent id and does not raise
Failure/Error:
payment_intent_response = Stripe::PaymentIntent.retrieve(
payment_intent_id,
stripe_account: stripe_account_id
)
VCR::Errors::UnhandledHTTPRequestError:
================================================================================
An HTTP request has been made that VCR does not know how to handle:
GET https://api.stripe.com/v1/payment_intents/pi_3P8hNGKuuB1fWySn0dvhu9lG
VCR is currently using the following cassette:
(...)
```
Currently RSpec warns these specs like this:
```
WARNING: Using `expect { }.not_to raise_error(SpecificErrorClass)` risks false positives, since literally any other error would cause the
expectation to pass, including those raised by Ruby (e.g. `NoMethodError`, `NameError` and `ArgumentError`), meaning the code you are intending
to test may not even get reached. Instead consider using `expect { }.not_to raise_error` or `expect { }.to raise_error(DifferentSpecificErrorClass)`.
This message can be suppressed by setting: `RSpec::Expectations.configuration.on_potential_false_positives = :nothing`.
Called from /path/to/spec/lib/stripe/payment_intent_validator_spec.rb:53:in `block (7 levels) in <main>'.
```
The warnings are super accurate in this particular case: the inner
assertion is not actually getting reached due to a previous unrelated
error.
Since there's an inner assertion already, I think it's best to
completely remove to `raise_error` negative block, since it just hides
errors and buys us nothing.
By removing it, the underlying error surfaces:
```
1) Stripe::PaymentIntentValidator#call as a guest when payment intent is valid valid non-3D credit cards are correctly handled behaves like payments intents from Visa returns payment intent id and does not raise
Failure/Error:
create(:payment, amount: payment_intent.amount, payment_method:,
response_code: payment_intent.id, source: pm_card)
NoMethodError:
undefined method `has_query_constraints?' for Stripe::PaymentMethod:Class
elsif (klass || self.klass).has_query_constraints? || options[:query_constraints]
^^^^^^^^^^^^^^^^^^^^^^^
Shared Example Group: "payments intents" called from ./spec/lib/stripe/payment_intent_validator_spec.rb:75
# ./spec/lib/stripe/payment_intent_validator_spec.rb:16:in `block (3 levels) in <main>'
# ./spec/lib/stripe/payment_intent_validator_spec.rb:19:in `block (3 levels) in <main>'
# ./spec/lib/stripe/payment_intent_validator_spec.rb:53:in `block (7 levels) in <main>'
# ./spec/base_spec_helper.rb:208:in `block (2 levels) in <main>'
# ./spec/base_spec_helper.rb:155:in `block (3 levels) in <main>'
# ./spec/base_spec_helper.rb:155:in `block (2 levels) in <main>'
# -e:1:in `<main>'
```
Capybara helpers already wait for the content to show up (and we already
have a default of 10 seconds configured), so I don't think waiting more is
actually the problem in these specs.
But if we wanted to wait more, I think it's better to pass the `:wait`
option to capybara matchers, because that's a "maximum waiting value"
but we'll still proceed earlier if the content shows up.
Using the same idea, I changed the positive assertions to happen first,
because negative assertions do spend "max wait time" waiting, while
positive assertions only wait until the content shows up.
##### Before
```
$ bin/rspec spec/system/admin/order_cycles/simple_spec.rb:460
Running via Spring preloader in process 79308
Run options: include {:locations=>{"./spec/system/admin/order_cycles/simple_spec.rb"=>[460]}}
As an administrator
I want to manage simple order cycles
as an enterprise user
that is a manager of the coordinator
when variants are hidden via inventory settings
Capybara starting Puma...
* Version 6.5.0, codename: Sky's Version
* Min threads: 0, max threads: 4
* Listening on http://127.0.0.1:51103
shows a warning when going to 'outgoing products' tab
Finished in 3.95 seconds (files took 0.45949 seconds to load)
1 example, 0 failures
```
##### After
```
$ bin/rspec spec/system/admin/order_cycles/simple_spec.rb:460
Running via Spring preloader in process 79234
Run options: include {:locations=>{"./spec/system/admin/order_cycles/simple_spec.rb"=>[460]}}
As an administrator
I want to manage simple order cycles
as an enterprise user
that is a manager of the coordinator
when variants are hidden via inventory settings
shows a warning when going to 'outgoing products' tab
Finished in 4.03 seconds (files took 0.49981 seconds to load)
1 example, 0 failures
```
Before:
```
$ bundle exec rspec -e ".render_as"
(...)
Run options: include {:full_description=>/\.render_as/}
WARNING: Using the `raise_error` matcher without providing a specific error or message risks false positives, since `raise_error` will match when Ruby raises a `NoMethodError`, `NameError` or `ArgumentError`, potentially allowing the expectation to pass without even executing the method you are intending to call. Actual error raised was #<ActionController::BadRequest: report_format should be in [:csv, :json, :html, :xlsx, :pdf]>. Instead consider providing a specific error class or message. This message can be suppressed by setting: `RSpec::Expectations.configuration.on_potential_false_positives = :nothing`. Called from /path/to/spec/lib/reports/report_renderer_spec.rb:34:in `block (3 levels) in <main>'.
.
Finished in 0.02544 seconds (files took 4.08 seconds to load)
1 example, 0 failures
```
After this patch:
```
$ bundle exec rspec -e ".render_as"
(...)
Run options: include {:full_description=>/\.render_as/}
.
Finished in 0.02488 seconds (files took 4.09 seconds to load)
1 example, 0 failures
```
This spec was using a very old syntax no longer supported by RSpec. It's
not currently influencing specs result because the spec running into
the error is currently set as "pending". However, the spec is still run
and the error is still visible.
Fixing the syntax does not fix the spec, but lets it get a bit further.
It looks like puma finds the file only under `/.well-known/dfc` and not
`/.well-known/dfc/` with a slash in staging environment while it works
here in dev and test.
And in any case, just placing the file in `public/` doesn't produce the
right content type.
