Make sure failure to delete due to dependent objects is handled through
activemodel errors and not by rescuing
`ActiveRecord::DeleteRestrictionError` exceptions.
Previously we would display two alert prompts, and we would weirdly
display the content of our 500 error page on top of the screen.
Now, we display a flash error message explaining the reason to fail to
remove it.
Make enterprise removal use turbo, which provides the following
benefits:
* More responsive removal since there's no full page reload.
* A success flash message (previously nothing was displayed).
* No double alert prompt.
It also goes in the direction of removing mrujs in favor of turbo.
Previously, `null` and empty value would be confused when a customer is
removed, resulting in incorrect pending changes being added, and thus a
"You have unsaved changes" message getting displayed and the save button
not getting disabled.
* Keep save bar visible as long as there's a customer form displayed.
* Only display "You have unsaved changes" when there's any difference
from the original values. If form changes are reverted, hide that
note.
* Similarly, only let the button be enabled if there are any actual
changes to be saved.
We only support one of filter by inventory variants or filter by variants
at any given time, based on enabled feature. If both features inventory
and variant tag are enabled, variant tag takes precedence.
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`.
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.
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.
This link would go to the enterprise edit screen, but didn't successfully select the payment methods panel.
Ideally, the spec would try to follow the link and verify that you can see the Connect with Stripe button. But it opens the link in a new tab and I'm not sure how to test that.
Capybara polls under the hood as well. So we do something similar here
but tailored to the tested code. This reduced the test run time on my
machine from 35 seconds to 15 seconds.
Working within a shadow root of the web component isn't well supported
by Capybara and I needed to find some workarounds. It's not pretty but
it works (on my machine). *fingers crossed*
And demonstrate the use of puffing-billy browser proxy.
Billy can cache and record responses to browser requests. For that to
work we need to allow network connections and disable VCR. But instead I
found that the Billy proxy is just like any other Ruby backend code and
its connections can be recorded with VCR instead.
And instead of stubbing requests via Billy.proxy, we can use standard
Webmock `stub_request`. Now we use puffing-billy just to relay browser
requests via our Ruby app.
