-
-
Notifications
You must be signed in to change notification settings - Fork 93
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
Configurable modal behavior? #185
Comments
Warning is only a default behavior when you didn't set handlers. Use Capybara handlers and there won't be a warning https://www.rubydoc.info/gems/capybara/Capybara%2FSession:accept_confirm. So first of all how did you end up with a test that ignored handling dialog box? |
I didn't write the application. I often inherit legacy applications for maintenance and updates and don't have control over what state they're in. Having just a warning allowed the previous developer to let the code base degrade by not making a decision about modal handling and by littering the test output with logging information. Not only that, but it was difficult to recover from once it was in that state. As an alternative to making it configurable, I think a good option would be to always be strict and fail the test. I don't see the benefit of downgrading this to a warning if the only options are to leave it as is or add a handler to remove the warning. Regardless, I appreciate your response and thank you for maintaining this library. |
I see your point, sounds good! Plenty of other issues though, if you can start on the implementation I can guide you! |
Great! Will do! |
Would there be interest in making the behavior around modals configurable? The current default is to issue a warning. I'd be interested in seeing a few options:
3a. possibly update this to include the file and line number so its easier to find
Why?
I try to keep my test output clean and free of logs. Easy enough to theoretically fix by following the default warn output, but it took a few steps to figure out which rspec tests were throwing warnings and on which lines. First I tried to modify my bundled gem to raise instead of log. Unfortunately, this just caused timeouts. I then added the
--format documentation
flag so I could see which spec names had the issue. I then had to lookup that name to find the file and, for longer tests, it was trial and error to see which action was triggering a modal. Perhaps there's an easier way to do this that I don't know about. My goal is to make this easier via strict mode or ignore it with auto_accept mode.The text was updated successfully, but these errors were encountered: