I have an odd scenario that I can’t figure out how to test.
iOS has an annoying behavior where if a user declines push messages, they are effectively locked out of receiving pushes for a long time. There are ways around it, but they involve resetting the phone’s date, uninstalling the app, and a bunch of things that are extremely unreasonable to ask a user to perform on their phone.
Push messaging is really important in our application, so we don’t want to display the Apple push registration confirmation dialog until we are absolutely sure the user will say yes. To accomplish this check, in our webview-driven app, we display our own dialog to the user explaining to them what they get from accepting push messages, and then if they accept, we use JockeyJS to send a message to the iOS app from our webview session telling the app that it’s OK to show the Apple dialog. Jockey accomplishes this communication between the webview and Objective-C code through the use of a custom URL structure (it’s
I am at a loss for how to test this other than just using my fingers and eyes. My first instinct was to do an integration test, but since the dialog displayed is iOS and not part of the DOM, I can’t use Capybara matchers to test whether or not the iOS dialog has been triggered by the HTML dialog. This behavior is fairly tightly coupled to the browser, so I’m having trouble writing Jasmine specs that prove the behavior is correct.
I should add that the simulator sometimes “remembers” your push message registration state, so you can’t just re-run tests in iOS easily as far as I can tell.
There are a couple of ways I’d be satisfied that there’s coverage here:
- Confirm a call was made to a
jockey://URL from the app (can one listen for this in RSpec/Capybara?)
- Confirm a certain browser event was fired (Jockey’s events are like jQuery’s so you define them with
Jockey.on()and trigger them with
Any Capybara superheroes with any ideas of how to properly test this scenario?