search

microsoft / axe-windows

Automated accessibility testing engine for Windows applications
MIT License
136 stars 62 forks source link

[Feature Request] Provide a way for .a11ytest files to be retained even if a scan produces no errors #935

Closed renishnair-viper closed 1 year ago

renishnair-viper commented 1 year ago

In IScanner.Scan() method output file of .a11ytest is only created when there is an error. There is a note added (Note: no output files will be written if no errors were found.) It should be based on some settings if there is no error but we want to review the file later it is not possible at the moment. So it should be based on some settings if the user wants a file each time to be generated whether there is an error or not they can set the setting and get the file. image

marcelwgn commented 1 year ago

Out of curiosity, do you mind me asking what processing you are doing with the a11ytest result file and how it would help having a result even if there were no errors? Is it about the screenshot that is part of it?

renishnair-viper commented 1 year ago

We have created an automation unit test case for our project using axe-windows. Suppose we are running the automation unit test every week after development changes and sometimes we encounter an error if we are having the last working file without any error we can compare and keep track of what minor or major changes have affected so we are getting error.

DaveTryon commented 1 year ago

I have a diagnostic branch (see changes) that adds this functionality, but it's on the ConfigBuilder instead of IScanner.Scan. It's not production-ready (it would still need unit tests, documentation, and CLI support), but we'll triage this and see how it lands with respect to other work that our team owns.

microsoft-github-policy-service[bot] commented 1 year ago

This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights!

DaveTryon commented 1 year ago

We agree that this makes sense. Plan is to control the setting via the ConfigBuilder, as implemented in the branch mentioned above. Relatively low priority compared to other things currently on our backlog. A community contribution might help it to get implemented more quickly.

codeofdusk commented 1 year ago

Released as part of 2.2.0. Closing as complete.