If you’ve spent any time building cloud-native systems, you’ve probably tripped over the tricky beast that is gRPC streaming. It’s powerful, flexible, and feels like magic when it works. But the minute you need to test it? Suddenly, you’re in “hold my coffee, I need a week” territory.
One of the most common places we see gRPC streams in the wild is when clients connect to asynchronous message buses like Google Pub/Sub. It’s a natural fit: Pub/Sub shovels messages at you as fast as your subscriber can handle them, and gRPC streams provide the async plumbing to get them from point A to B.
The question is: how do you test this without turning your CI pipeline into a distributed systems research project?
Deciding What to Test
When mocking or testing gRPC streams, the first decision is what belongs in your test.
- Do you want a unit or isolation test of just your gRPC client logic?
- Or do you want to run a system test that simulates the whole “Pub/Sub → gRPC stream → your app” pipeline?
If you’re testing the client code itself, mocking the gRPC server makes sense. You can simulate message arrival, stream ordering, and retry logic without pulling in an actual Pub/Sub topic. This is fast, lightweight, and works great when you want to exercise logic in isolation.
But if you’re testing how your system behaves under real-world conditions, including Pub/Sub in the mix pays dividends. One additional consideration is whether your app is a consumer, a producer or both. Typically, consumers can be run with a simulated message bus (aka Pubsub service) to save on cloud infrastructure costs. Producers, on the other hand, may want to connect directly to the message bus to ensure that interactions are clean.
Why Test with Real Pub/Sub?
Using Pub/Sub as part of your load test brings realism that mocks just can’t replicate. For example:
- Backpressure and bottlenecks – Pub/Sub enforces quotas and flow control. If your subscribers can’t keep up, Pub/Sub will happily slow things down. That’s the kind of production-like behavior you want to see in testing.
- Operational quirks – Messages may arrive slightly out of order, be redelivered, or trigger retries. If your system can’t handle that, better to find out now than on a Friday night during an incident.
- Scale dynamics – Spinning up multiple subscribers against a real Pub/Sub topic is often the only way to flush out hidden resource contention issues.
In short: sometimes the best “mock” is no mock at all. By including Pub/Sub in your test environment, you can push load through the same asynchronous firehose your production system uses.
But What About Mocks?
Of course, not every test needs (or can afford) to spin up a real Pub/Sub topic. That’s where mocks and simulators shine.
Tools like proxymock can simulate Pub/Sub’s gRPC streaming interface. That means you can:
- Record real Pub/Sub traffic from your staging or production environment.
- Reuse that recording in a deterministic test that replays the stream exactly.
- Simulate load spikes or error scenarios without incurring Pub/Sub costs or latency.
Think of it like flight training: sometimes you fly the real plane, but sometimes you practice stalling and engine-out maneuvers in the simulator. Both are valuable, but you don’t want to mix them up.
The Testing Strategy That Works
So how do you balance mocks and real systems?
- Unit tests → Mock gRPC streams directly. Keep it fast and focused.
- System tests → Include Google Pub/Sub in the loop. Let it be the source of truth and the source of bottlenecks.
- Chaos or load testing → Use tools like proxymock to simulate traffic at scale, inject edge cases, or reproduce production incidents in a controlled way.
That way, you get coverage across the spectrum without burning out your team—or your budget.
Final Thoughts
gRPC streams are awesome, but testing them doesn’t have to be painful. By mixing real message buses like Pub/Sub into your system tests and leveraging simulators like proxymock for targeted scenarios, you get the best of both worlds: realism where it counts, mocks where it helps.
If you’re ready to stop wrestling with gRPC stream mocks and start running reliable, repeatable tests, give proxymock a try. It can simulate Pub/Sub streaming (and a whole lot more), so you can focus on building great software instead of debugging flaky tests.