Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Audit failures should not stop the test from running #7

Open
pangolingo opened this issue Aug 12, 2022 · 0 comments
Open

Audit failures should not stop the test from running #7

pangolingo opened this issue Aug 12, 2022 · 0 comments

Comments

@pangolingo
Copy link

I've observed that if a test fails because a page is not accessible, the remainder of the test block does not run. This results in issues being reported for a single page, but not for any other pages loaded in a test block.

Expected behavior:
The test should run to the end (barring other non-accessibility failures), even if a few of the pages visited fail the accessibility audit. Audit errors should be reported across all pages visited.

Actual behavior:
The test halts on the first accessibility error that it finds

Example:

RSpec.describe "Playbook", type: :system do
  around do |example|
    with_accessibility_audit_options do
      example.run
    end
  end

  it "renders all pages without error" do
    visit "/playbook"

    playbook_links = all(".application-main-content a[href^='/playbook']").map do |link|
      link[:href]
    end
    playbook_links.each do |url|
     # the first page visited that has an accessibility error will end the test
      visit url
    end
  end
end

I do realize that this issue/suggestion goes against the default behavior of Capybara - Capybara normally does not run the entire test if an assertion fails, or if it fails to visit a page. But it would be a great enhancement.

isen0011 added a commit to isen0011/capybara_accessibility_audit that referenced this issue May 8, 2024
Works on thoughtbot#21.

This doesn't completely fix the problem that is identified in thoughtbot#21, but
it is a step in that direction.  The idea is that, if the configuration
setting `accessibility_audit_skip_on_error` is set to true, if an `axe`
violation is detected, instead of generating an error it will instead
mark the test as `skipped` with the `axe` output as the message in the
skip output.

There is a problem with this approach, which is the same problem
identified in issue thoughtbot#7 - as soon as a single test is marked skipped or
failed, then the rest of the test is skipped.  This means that if a
test has both failing application logic and failing accessibility
validation, the first of those tests to fail will be the one that is
reported.  For a system test, since any interaction with the page will
trigger the accessibility tests, it is likely that the test will be
marked as skipped and the application logic failure will be hidden.

This can be solved by running the tests a second time with
`accessibility_audit_enabled = false` and comparing the results, but
that does require two runs through the test suite.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant