Updates and moves consumer/account folder into system

[filipefurtad0]

What? Why?

Relates to #7929

Moves and updates the specs in feature/consumer/account into system specs.

What should we test?

Green build.

Release notes

Moves and updates the specs in feature/consumer/account into system specs.

Changelog Category: Technical changes

[jibees]

You did not delete the old files?

[filipefurtad0]

I did, but somehow the changes were not picked up... I've used git mv as well, but over a directory.

It seems it's best to move files one by one.

[filipefurtad0]

Best to do it that way, to assure nothing gets lost. Moving back to in dev 👍

[filipefurtad0]

To nuke all changes in a branch I'm doing:

While on the to-be-nuked branch new_branch:

git reset --hard upstream/master
git push -f origin new_branch

This closes the pull request as it removes all commits. After committing again one can click the re-open (it is only active with new once there are new commits) with the button below. Not sure there's a better way to do this, but this seems to work.

[filipefurtad0]

Spec fails with this line, so I removed it - as it is not necessary, the modal is accepted by default.

Regardless of that we now have a warning here which goes:

Modal window with text `Changing your default card will remove shops' existing authorizations to charge it. You can re-authorize shops after updating the default card. Do you wish to change the default card?"` has been opened, but you didn't wrap your code into (`accept_prompt` | `dismiss_prompt` | `accept_confirm` | `dismiss_confirm` | `accept_alert`), accepting by default

[mkllnk]

The old spec just called accept_alert once the alert was displayed. But now we need to "expect" an alert before it happens and wrap the alert-causing code in a block. I added a commit to show you how we should use it now.

And as it turns out, it revealed a mistake in the translation file! This is a good example why testing for explicit strings is much better than expect(text).to eq I18n.t(:key).

[mkllnk]

Nice one! 😄

Now we just need a green build...

[mkllnk]

The old spec just called accept_alert once the alert was displayed. But now we need to "expect" an alert before it happens and wrap the alert-causing code in a block. I added a commit to show you how we should use it now.

And as it turns out, it revealed a mistake in the translation file! This is a good example why testing for explicit strings is much better than expect(text).to eq I18n.t(:key).

[filipefurtad0]

Thanks @mkllnk for pushing this forward! And for explaining your approach, too - that's really helpful 👍

[Matt-Yorkley]

👍