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

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

I mean automated tests

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.

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?

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

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

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.

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

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.

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

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

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

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

yea correct, assume different test suite

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.

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?

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.

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

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.

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