Create integration test cases for mobile devices

[data-sync-user]

We have extensive integration tests for websocket calls to the Autopush server, but we do not appear to have many test calls to the Autoendpoint HTTP interfaces. This means we could be delivering a buggy interface and have no way of easily detecting it.

┆Issue is synchronized with this Jira Task

[data-sync-user]

➤ JR Conlin commented:

Thanks, got interrupted before I could update this.

[KartikShrivastava]

Hello @jrconlin, I'm interested in contributing to mozilla's push service and have some experience working with web-push. Is this project welcoming new contributors? Please mention if there're any contribution guidelines, I couldn't find much info in the docs

[jrconlin]

We're very happy to welcome community help on any project. This issue is a bit complex though. Let me see if I can explain the challenge.

Mobile devices have very strict restrictions on battery use. Keeping a connection "live" uses up the battery very quickly, which will cause the app to be forced closed, or flagged by the operating system. To solve this, mobile OS providers offer a "free" way to send messages to devices. This service uses their internal, proprietary systems to send messages. We call these a "Bridge".

Where things become challenging is that these same systems may or may not provide things like a service emulator (Android FCM does, but Apple APNs does not, meaning you have to have a physical iOS device to test messages). In addition, an integration test is at the whim of the recipient service or device. The mobile device or emulator may not wake or respond immediately, which may cause a test with a short time-out to fail. Also, since the system is running on a different system, getting a success or failure back may not be easy.

Quite some time ago, I created a simple page that at least allowed our QA folk to test push on a mobile device. There are many problems with it (it uses a very old message encryption format, it would break due to DOM changes. The idea was fairly simple, though. Have a self-contained page that created a new subscription, generated a message, encrypted it using the subscription info, sent the encrypted message to the endpoint, then waited for the message to arrive, and validated that the message matched what it sent. This was all done in javascript within the browser because of yet another challenge with using the proprietary "bridge" messaging systems. Each application has it's own, private credentials that it is assigned to send messages. This means that we can't create a "testing" app that has the same messaging credential set as Firefox.

It's very much a challenge.

All that said, there are some things that would still be VERY useful.

1. If someone were to update the test page to use RFC8291 compliant aes128gcm encryption as well as the current aesgcm encryption format. (There are libraries that can do this, but you may have to dig around a bit.)
2. Fix some of the terrible Javascript code in there. (My apologies in advance. A lot of that code was lifted from a different project with a very different goal in mind.)
3. Document the challenges. This is a great way to find out what we need to do to simplify things, but having been involved in this for over a decade, it's very difficult for me to know what sort of things people don't already know.

In any case, thank you for even asking. Because of your question, I was able to put this answer together. Hopefully it helps, but even if it doesn't it might help someone else.

[KartikShrivastava]

Thanks for the the detailed information around this issue. I'll take a look at the tasks you mentioned, starting up with updating Webpush_QA code.