For the last six months I’ve been working on notifications, and they’re honestly way more interesting (and annoying to test) than the usual request/response flow. Most backend systems are built around the front end asking for data, middleware doing some processing, and then returning a response. Notifications flip that model: the backend decides “it’s time,” emits an event, middleware listens, transforms or enriches the payload, and the front end just displays it. That one-way, event-driven setup is great for product needs, but it makes manual testing way less straightforward. In this video I walk through why testing notifications is hard and what options you actually have. You can add a test endpoint to your main service, or build a separate test service so you don’t burn resources in production-ish systems. But the real pain point I hit was access management: my middleware team can push fake notifications into the same place the backend uses, and the front end can’t—so they keep pinging me to do it. My solution was to create scripts + a README so they can generate and send test notifications safely without giving them cloud console access (nope). I even started in Python, realized I was basically just shelling out to terminal commands, and switched to bash. The goal: faster end-to-end-ish testing, less manual work, and a tool one engineer can try before I unleash it on the whole team.