tldr; how to do end-to-end push notif. test / some...

# android-architecture

[ursus]

tldr; how to do end-to-end push notif. test / something that involved 3rd party service

[ghedeon]

No need for 3rd pary service, just a post request to Firebase with your app key and push token

[ursus]

I mean automated tests

[ghedeon]

On the phone now, but basically google "Test FCM with Postman" and make sure it's not very old because the API might have changed. Also, Firebase console has Test Notification functionally, but it's only for the Notification, not data push.

[ursus]

yes I know how to send that request via postman, but what I'm getting at is how to make this into a automated test 1) if its cool to send live requests in testing 2) should phone or server do it 3) doesnt the token expire after a while?

[ghedeon]

Well, I don't think testing google services in your app test suite is a good idea at all.

[ursus]

well thats pretty much what I'm asking, however push notifs are core messenger functionality so, I'm thinking something should be done

[ursus]

isnt that what integration tests are for?

[ghedeon]

usually you just make sure the integration went well during the development by sending pushes on your staging environment, for example. Then check once again on live and then pretty much rely on Google and it's analytics, to see if it keeps working. I wouldn't automated anything that I don't control in my app.

[ghedeon]

even my own backend, it's just unreliable.

[ursus]

well, what are integration tests for then if not the real imlementations?

[ghedeon]

it's a broad term. Integration, obviously tests integration between multiple units. Now, you define what an unit is. For me it's different parts of my app. Yes, it might contain backend calls but I'd have them mocked in this case, because I don't want to rely on something flaky, that I don't control.

[ghedeon]

You can have some smoke tests automated, to run them from time to time, to see if external dependencies are still there, but idk.. most of the time teams don't have enough resources to get to that point. Also, you'll be rewriting that stuff a lot.

[ursus]

well I feel the same way, I dont want to break my build if backend is fucked up but, somebody should know about it, or rather the 3rd party is broken

[ursus]

so a smoke test should break a build?

[ghedeon]

no, I wouldn't block PR because of such test

[ursus]

and what would you block if anything? lets say its once every midnight kind of test, how would you surface it?

[ghedeon]

it's extra and mostly seen as luxury. Not part of your regular test suite that you run on every PR

[ursus]

yea correct, assume different test suite

[ghedeon]

as I said, I wouldn't waste time with this at all. The awareness that you're looking for, when something is down, is handled by proper monitoring (dashboards, alerts, etc) and not by clients testing services.

[ursus]

hmm I'm not sure what you mean, lets say there is nothing in the organization for this, you'd put this on a CI nightly script, and surface it on a dashboard somewhere?

[Pablichjenkov]

I would suggest doing a closed loop when delivering the notification, even in production. If you feel something may be failing during Notification delivery. Every time you receive a notification in the App then send a received ok message back to the server. You can put in this message data to identify the receiver and mark the delivery as successful.
That way you can start doing your own stats and see what percentage usually fails, what type of devices, what country and so on.

[ursus]

okay but, you wouldn't put any build breaking on this correct? If not, then it's just nice-to-have awareness?

[ghedeon]

yes, that's right. Stopping build because one of the endpoints is down doesn't make sense. In case of pushes it's even hard for me to imagine what can be automated there.

[ursus]

In ideal world I'd imagine to have a stable testing fcm token, and "curl" a request at fcm.google and verify FcmService.onMessageReceived arrived within some timeout

[ursus]

Okay pivot, server send the request at fcm.google.whatever, it response with status if given token was delivered or not

[ursus]

so, unit tests on the server to the edge of that call are a give, but maybe some merge might fuckup the implementation of that real fcm call, does this make sense to assert somehow with a live request?