7 posts tagged with "Testing"

When I started Xcepto, I wasn't trying to build a testing framework.

I was trying to solve a messaging problem.

RabbitMQ systems are notoriously awkward to test: events arrive asynchronously, processing order is not guaranteed, listeners must be configured before messages are published.

A few seconds here. A few seconds there. Suddenly nobody runs tests locally anymore because waiting breaks fast iteration.

And once engineers stop running tests often, test confidence quietly drops.

That's the pain of cross-platform development. Especially when switching between async .NET and Unity coroutines.

• Backend runner: ✔ works
• Frame-spaced execution: ❌ blocks, ❌ freezes, ❌ partially executes

Runtimes often leak into behavior. But a good abstraction should preserve semantics.

For years, system tests have been written with Arrange–Act–Assert.

That works — until asynchronous behavior enters the picture.

AAA implicitly assumes synchronicity: Arrange, then Act, then Assert — as if the system has already settled. But distributed systems don't behave like that.

Most developers run into this eventually.

A test blocks forever. Seconds turn into minutes. Eventually, GitHub kills the job after an hour. But the damage has already been done: CI costs have silently piled up.

If test code were just explicitly wired dependencies in local variables, composition would be straightforward.

But once you introduce asynchronous processing, messaging, or higher-level test frameworks, what the test is actually doing becomes opaque.

• Execution order becomes implicit.
• Data flow becomes hidden.
• Coordination turns into guesswork.

The problem isn't your services. It's the assumption that processing time is deterministic.

• What if the system is slower today?
• What if the delay is too short... or unnecessarily long?

This is time-driven testing. It's fundamentally non-deterministic.