Invert "not_to have" as "to have_no" in feature specs

[aduth]

Why: Theorizing that we're waiting Capybara.default_max_wait_time (0.5s) for each instance of this where we expect it not to exist.

See: https://www.cloudbees.com/blog/faster-rails-tests/

[aduth]

@mitchellhenke found this piece of documentation, which might imply that this is handled automatically?

Capybara's RSpec matchers, however, are smart enough to handle either form. The two following statements are functionally equivalent:

expect(page).not_to have_xpath('a')
expect(page).to have_no_xpath('a')

https://github.com/teamcapybara/capybara#asynchronous-javascript-ajax-and-friends

It's not really clear if "functionally equivalent" is in having the same assertion outcome, or as in it will also automatically shortcut the absence in the first example and avoid waiting. Since the preceding blurb of text is describing a case where an element is expected to be removed after a delay, it's possible that it's not talking about shortcutting the absence.

Another similar discussion, with no clear consensus: rubocop/rubocop-rspec#378

[zachmargolis]

Have we done a before/after on the specs here to check the timing?

[aduth]

After testing locally by setting our default_max_wait_time configuration to a much higher timeout (30 seconds), there's no noticeable difference from these changes, so it appears that Capybara is indeed handling this automatically.