Don't

Most acceptance tests I see are testing the happy path, and therefore they should definitely follow this advice.

Sometimes I see acceptance tests that are like:

scenario "the happy path", :js do
  # great practices in here. stellar work
end

scenario "the user's favorite color is incorrect", :js do
  # ... shortcuts that get us to the page most quickly ..., then
  fill_in "Favorite color", with: "Blue"
  click_on "That is definitely my favorite color. It's absolutely not yellow"
  expect(page).to have_content("You may not cross this bridge")
end

Where the happy path follows this advice, but the other test wishes it were a request test but it needs JS.

What do you think of this practice? Do you think it warrants using "avoid" instead of "don't"?

I think I'm missing context on the question. Where in this example code is an [id], CSS selector, or JavaScript?

Er, sorry about that. The [id] happens in here:

  # ... shortcuts that get us to the page most quickly ..., then

I was unimaginative and couldn't quickly find a real code example where we were sloppy in the lead-up to the error case code path.

(And the JS is whatever is required to get the content on the page. You can imagine a single-page app or some other monstrosity.)

Some meta thoughts:

• maybe an implication here is that error paths should be tested at a totally different layer.
• maybe there's no excuse for circumventing the good, accessible way to navigate, even if it is more verbose.

maybe an implication here is that error paths should be tested at a totally different layer.

Personally, I'm exploring that space with efforts like thoughtbot/action_dispatch-testing-integration-capybara, but this could be covered with view or component testing, separate from the browser environment.

maybe there's no excuse for circumventing the good, accessible way to navigate, even if it is more verbose.

There are for Capybara to locate, interact with, or assert invalid fields.

For example, the :field selector accepts a valid: Boolean filter and a validation_message: String filter to affect query scope based on an element's validity state (which requires a Real Browser to function, but doesn't require any JS).

Similarly, the citizensadvice/capybara_accessible_selectors gem extends :fillable_field and other form control selectors to accept a described_by: filter based on a form control having text content that references it through the aria-describedby attribute.

Please let me know how I can help. I believe I merged.