11 posts tagged with "Xcepto"

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.

Did you ever copy-paste builder methods across similar builders and just accept it?

This is especially painful when creating multi-stage fluent APIs — ones that only expose valid methods at each build step.

CRTP (Curiously Recurring Template Pattern) eliminates this entirely. It lets base classes return the concrete builder type instead of the abstract one.