The refresh token is usually valid for a year but it can be revoked at
any time. When we try to use it and it's expired, we should remove it
from the account record and notify the user. They can then refresh the
authorisation.
This makes testing much easier. But probably also good for users to
revoke any access via OIDC apps. It also enables users to then connect
to a different account, or just renew the current connection.
The provider name and uid are currently stored on the user model but
it's better to move them to their own table. They are only needed in
certain situations, only some users have an account and we are now
storing a lot more.
* Clarify that it's a request spec, not testing a controller directly.
* Use `before` block to avoid side effects changing config at load time.
* Better name the test action as request instead of plain "subject".
* Move assignments into `before` block instead of variable.
The original Spree user factory was adding the admin role by default.
Since we don't do that anymore, we don't need to remove it for normal
users. We also need to add it only once to admin users.
Model spec shouldn't know about the undelying call to stripe. Replaced
request stubs by payment method stubs.
Consolidate #credit spec in one `describe` block
- copied the relevant code from the new Active Merchant version
- Add spec to cover the scenario of saving a card when paying by card
- Fix Stripe stub.
I used stripe stubs for the new scenario because storing a card on
stripe depends on some client side interaction with Stripe. We can't
capture that with VCR.
This avoids unnecessary second message when left blank:
> can't be blank
> is not a number
Ok this is a little confusing. Why is there a separate presence check above, and why is it only for measurable units, when we still require a number for _all_ units? Because, for 'items', we allow a blank value then auto-set it to 1.
I don't know if it's really necessary, but that's how it currently works...
In test-driven development, you run tests and expect them to fail.
Waiting for the results unnecessarily long just slows down development.
And even though CI can be slow, we should aim for good performance of
our code. Long wait times can hide performance bottle necks.
If anyone struggles with the default value, we can add an environment
variable to adjust the wait time to your machine in .env.test.local. But
this may just work for everyone.
