unknown

Testing event-sourced systems requires a shift from verifying state to verifying emitted events. By aligning tests with Event Storming's domain language using a Given/When/Then pattern, tests become more than verification — they serve as living documentation and specification. A custom PHPUnit base class (EventTestCase) abstracts event store management and command dispatch, while also generating visual Event Storming diagrams from test data. This approach bridges the gap between domain workshops and production code, turning testing from a burden into a communication and documentation tool.

From Events to Insights

Welcome to PHP Dev, a dedicated space for sharing knowledge about PHP and its ecosystem (only PHP directly related).
Help us find good articles and blogposts and provide links. Upvote or downvote, after reading, it's essential

PHP Dev

What if running your tests auto-generated Event Storming diagrams?

Most developers treat tests as a chore and write them to satisfy CI, forget them until they break.

But what if your test suite could do something more?

When you combine Event Sourcing, CQRS, and DDD, something elegant happens: your tests stop being a verification burden and become a bridge. A bridge between domain experts and developers, between workshops and working software.

The insight that changed my thinking:

In traditional CRUD systems, you ask: "What state is now in the database?"

In event-sourced systems, you ask: "What events were recorded?"

That shift is subtle. The consequences are profound.

When you model your tests using the same ubiquitous language from your Event Storming sessions, something surprising becomes possible: the test runner does not just verify your code. It also generates visual Event Storming documentation automatically.

The orange sticky notes you know from from your workshop. Rendered. From your test output.

I wrote about this journey in my latest article: from the fundamental question of how to test immutable event streams, to building a EventTestCase base class that handles all the plumbing, to watching tests produce living architecture diagrams.

<p>What if running your tests auto-generated Event Storming diagrams?

Most developers treat tests as a chore and write them to satisfy CI, forget them until they break.

But what if your test suite could do something more?

When you combine Event Sourcing, CQRS, and DDD, something elegant happens: your tests stop being a verification burden and become a bridge. A bridge between domain experts and developers, between workshops and working software.

The insight that changed my thinking:

In traditional CRUD systems, you ask: &quot;What state is now in the database?&quot;

In event-sourced systems, you ask: &quot;What events were recorded?&quot;

That shift is subtle. The consequences are profound.

When you model your tests using the same ubiquitous language from your Event Storming sessions, something surprising becomes possible: the test runner does not just verify your code. It also generates visual Event Storming documentation automatically.

The orange sticky notes you know from from your workshop. Rendered. From your test output.

I wrote about this journey in my latest article: from the fundamental question of how to test immutable event streams, to building a EventTestCase base class that handles all the plumbing, to watching tests produce living architecture diagrams.</p>