1a5eb5b39a
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>'
```
Open Food Network
The Open Food Network is an online marketplace for local food. It enables a network of independent online food stores that connects farmers and food hubs (including co-ops, online farmers markets, independent food businesses, etc) with individuals and local businesses. It gives farmers and food hubs an easier and fairer way to distribute their food.
Supported by the Open Food Foundation and a network of global affiliates, we are proudly open source and not-for-profit - we're trying to seriously disrupt the concentration of power in global agri-food systems, and we need as many smart people working together on this as possible.
We're part of global movement - get involved!
- Join the conversation on Slack. Make sure you introduce yourself in the #general channel and join #dev for all tech-related topics.
- Head to https://openfoodnetwork.org for more information about the global OFN project.
- Check out the User Guide for a list of features and tutorials.
- Join our discussion forum.
Contributing
If you are interested in contributing to the OFN in any capacity, please introduce yourself on Slack, and have a look through the OFN Handbook.
Our GETTING_STARTED and CONTRIBUTING guides are the best place to start for developers looking to set up a development environment and make contributions to the codebase.
Hacktoberfest 🎉
Are you participating in Hacktoberfest? Go check out our Welcome New Developers project board! We have curated all issues we consider to be a good starting point for new members of the community and categorized them by skills and level of complexity. Have a look and pick the one you would prefer working on!
Provisioning
If you're interested in provisioning a server, see ofn-install for the project's Ansible playbooks.
We also have a Super Admin Guide to help with configuration of new servers.
Testing
If you'd like to help out with testing, please introduce yourself on the #testing channel on Slack. Also, do have a look in our Welcome New QAs board for some good first issues, both on manual and automated testing (RSpec/Capybara).
We use BrowserStack as a manual testing tool. BrowserStack provides open source projects with unlimited and free of charge accounts. A big thanks to them!
We use KnapsackPro for optimal parallelisation of our automated tests. KnapsackPro offers unlimited plans for non-commercial open source projects, like ours - a big thanks to them!
Licence
Copyright (c) 2012 - 2024 Open Food Foundation, released under the AGPL licence.