Quality and context engineering

Writing tests and writing context for an AI agent solve the same problem: making explicit, verifiable and re-runnable what only existed in the head of whoever wrote it.

What is practice, and what is still intention

A test suite with xUnit and declarative validation with FluentValidation are the default in what I write, and most of the projects I touch have both.

Numbered specifications versioned alongside the code and agent context versioned in the repository are recent, and still in a minority. I prefer to state where the practice already is rather than where I would like it to be.

Integration tests with ephemeral containers I use little, and in recent things.

Why xUnit and FluentValidation go together

They solve the same problem at different moments. The test proves the rule works; declarative validation makes the rule readable at the point where it appears, instead of scattered in ifs across the service.

In practice that means unit tests for domain rules, written as an executable specification of the behavior, and one validator per command running in the pipeline before the handler, so that the operation does not even start if the data is no good. The validation returns every problem at once, not the first.

What I do

• Treat the unit test as an executable specification of the domain rule
• Keep validation declarative and in the right place, so that the error message belongs to the business and not to the database
• Write a numbered specification before implementing, versioned together with the code; see Design before implementing
• Version the context an AI agent needs to work in the repository: conventions, architecture, what not to do
• Review code against a written, citable standard, instead of against opinion; see Code review and standards
• Record the friction that cost a lot, so the next person does not pay again; see How I debug

Where I applied it

Industrial monitoring · Experience · Payments and anti-fraud

PMQ Suite

What I have not done yet

Having a suite is not having coverage. When I say most of what I touch is tested, I am saying the projects have a suite, not that the code inside them is covered, and that second thing I do not measure. Integration tests with ephemeral containers I use little, contract tests between services I have never done, and I do not work with mutation testing or load testing.