Daniel Maß

I'm happy to announce, that Xcepto version 10 is coming soon!

It brings a bunch of changes, improving the readability of tests even further.

Among these changes are:

• Builders for assembling states with shared methods like .WithName("MyState")
• Extension methods replacing var adapter = builder.RegisterAdapter(new Adapter()) with var adapter = builder.AddRestAdapter().Build(). This opens up the opportunity to standardize adapter creation with builder methods like WithSomething() that can be shared across adapters.
• Promised values will allow users to capture the future results of steps and use them for following steps. To achieve that, Promise<MyResult> will be passable to state builders as an argument.

There will be more detailed information coming soon!

Xcepto is still new, and that created an unexpected problem: AI agents were bad at writing Xcepto tests.

Not because the tests were impossible — but because the model had almost no reliable context. When I asked Codex to write Xcepto tests, it usually tried to infer the framework from whatever it could find. Sometimes it checked out Xcepto.NET somewhere temporary. Sometimes it guessed APIs through reflection. Sometimes it copied local fragments without really understanding the test model.

Because event-driven systems make behavior observable.

In a typical layered application: "A user clicks a button. Then what?" Dozens of methods execute across multiple layers — hidden control flow, opaque state changes, unclear behavioral contracts.

But an event-driven workflow is explicit:

HiveShard is a distributed simulation runtime where independent components communicate through events and advance a deterministic world state through lockstep ticks.

The problem? Traditional tests assume execution flow follows control flow. That assumption falls apart quickly in distributed systems.

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.