cuprite
cuprite copied to clipboard
rubycdp
Configurable modal behavior?
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:
- strict: raise an error and fail the test
- auto_accept: like the current default but no longer issue warnings
- warn: the current default 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.
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!