If I re-record cassettes for these specs using my test API key, I get
the following errors:
```
1) Stripe::CreditCardRemover#remove Stripe customer exists and is not deleted deletes the credit card clone and the customer
Failure/Error:
Stripe::PaymentMethod.create(
{
type: 'card',
card: {
number: '4242424242424242',
exp_month: 8,
exp_year: Time.zone.now.year.next,
cvc: '314',
},
},
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.
# ./spec/lib/stripe/credit_card_remover_spec.rb:16:in `block (3 levels) in <main>'
# ./spec/lib/stripe/credit_card_remover_spec.rb:44:in `block (4 levels) in <main>'
# ./spec/lib/stripe/credit_card_remover_spec.rb:56:in `block (4 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>'
```
Use test payment methods instead as suggested by the error.
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>'
```
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
```
Rails 4.1 added time helpers but we never bothered using them. But now
I'm getting rid of the Timecop dependency and use standard helpers.
Beware though that the new helpers always freeze time. When you travel
to a certain date then the clock stops ticking while Timecop maintained
the passing of time.
The freezing of time could cause problems if you are trying to enforce a
timeout. But all current specs don't seem affected.
In most cases, the freezing will make it easier to avoid flaky specs.
When we test our code coverage compilation, it breaks the code coverage
report for the current rspec process. By running that code separately,
we gain a correct coverage report for the rest of the code again.
So unfortunately, we can't report on the code coverage of this
particular task and have to ignore it. But at least CI depends on the
correct function of this task and would fail if it didn't work.
Apparently, Rake's way of reloading the task code confuses the code
coverage report. Code tested by rake task specs was not recognised as
covered even though it was.
Per review, the check is done on the same enterprise as the one use to
initialize ScopeVariantToHub. So it makes sense to move the actual
feature check to ScopeVariantToHub#scope
This class was originally built to flexibly accept paramters in any order. It also allowed you to specify multiple of the same type of parameter, with the later one overriding the earlier.
This is too flexible and likely to cause mistakes. And besides, we don't use that feature!
