Written by Fedor Novikov and Alexander Aronov, Engineering Managers at Bolt.

Introduction

For anyone who develops software, writes code, and eventually writes tests (unit, integration, or component), this article is for you. It doesn’t matter if you’re working on a microservice, a monolith, a frontend app, a mobile client, or a shared library. We’ve all been there: tests that are so complicated they’re harder to read, write, and refactor than the production code they’re meant to validate. If your test suite feels like it’s fighting you, you’ve come to the right place.
You should care because this isn’t about test theory, but about readable, explicit tests that reduce the cost of change, make failures easier to diagnose, and let you evolve your code without fighting your suite. And if you want AI to help you write, review, and refactor tests, your tests need a structure that’s easy to understand and validate.

Often, the reason is the complexity introduced by tangled mocking and setup utilities, as well as the massive amounts of imperative logic (if statements) required to manage test state. We believe logic should be in your application, not in your tests.

To address this, we refined the classic Arrange-Act-Assert pattern into a more robust approach: AAAAA Testing (pronounced “Penta A”), which stands for Arrange, Anticipate, Act, Assert, and AI.

If you’re familiar with the AAA (GWT) testing theory, you can skip this section and move on to the next part — Anticipation.

AAA testing approach

The Arrange-Act-Assert (AAA) pattern is a widely adopted and excellent starting point for test structure. The AAA pattern is described and recommended by well-known figures and organisations in software engineering, including Martin Fowler¹ and Bill Wake².
It dictates 3 simple phases:

Arrange: Prepare the initial state, data, and preconditions for the test. This often involves initialising database data or creating test fixtures.

Act: Perform the single action under test. This is typically calling a function or hitting an API endpoint.

Assert: Verify the outcome, checking the return value, database state, and any side effects.

A quick detour: AAA vs. Given-When-Then (GWT)
A common point of confusion is whether AAA is the same as Given-When-Then (GWT).

They represent fundamentally different approaches to test design. Although AAA and GWT both follow the same 3-phase structure (prepare, perform, verify), they emphasise different communicative goals. Given-When-Then originated in Behaviour-Driven Development (BDD)³ - to make tests readable to non-technical stakeholders. A single GWT scenario often encodes an entire user workflow and may embed conditional logic in step definitions.
The AAA pattern, by contrast, enforces atomicity⁴: one action per test, explicit state in Arrange, direct checks in Assert, with no branching. This structural discipline makes AAA tests more declarative — they state what holds at each phase rather than how to verify complex scenarios, resulting in higher readability and lower maintenance burden compared to GWT's implicit step logic⁵.

GWT:

Abstracts the details: Focuses on the "happy path" and business logic while hiding the technical implementation.
Broad scope: Encourages covering full scenarios, though this can sometimes lead to trying to test everything in a single go.
Complex flow: Often relies on imperative steps that include conditional logic ("if" statements) to handle complex behaviours.

AAA:

Details matter: clearly define the atomic steps before taking action.
Focused scope: Discourages comprehensive tests, favouring small, isolated checks instead.
Linear flow: Keeps the test declarative and straightforward, usually avoiding the need for complex conditional logic.

Probably now you’re wondering how the AAA code can be better than the GWT one. It has more lines, and now we need to know how to insert products, mock the image search call, and so on.
But there’s an elephant in the room: ProductUtils from the example above conceals a lot of code inside. You might not care about it at first, but when you need to add one more property, you look inside, and what do you see?

The problem with ‘if’ statements: When logic starts to smell

The utils use other utils based on conditional logic, and you can see how this becomes increasingly complicated and tightly coupled to each entity and operation they have to support.
That’s “mocking hell”: tests that are hard to read, hard to refactor, tightly coupled with, and sometimes more complex than the code they’re supposed to protect.

The setup phase turns into a forest of conditions:

If the payload contains X, return Y.
If the flag is false, throw an error.
If the retry count is N, simulate a timeout.

What used to be “Arrange” becomes a miniature implementation of business logic, and the test ends up tightly coupled to both the implementation and the mock wiring. It creeps into verifying internal and intermediate steps, leading to tight coupling between the implementation and the mock wiring.

But even with AAA, doesn’t something still feel wrong?

When we write tests for real systems, mocking external dependencies is often the most painful part. These dependencies can include third-party functions, API calls, message publishing, or reading from storage — we usually just want to “mock them out” to keep tests deterministic.
Over time, however, the test takes on a second role. It not only sets up data and verifies the outcome, but also has to predict and control every external interaction along the way. In practice, this means defining and validating what the system will send and what it should receive in return.

A good way to break this cycle is to stop treating external mocking as a side detail and make it an explicit phase of the test. In our approach, we separate external interactions into a dedicated step called Anticipate. We propose moving the coupling points into a separate function, which allows the rest of the test to remain clean.

Anticipate

We found that extracting third-party calls into separate functions makes mocking lightweight and far less coupled, since these calls are the primary points of coupling. Anticipate is the place where the test describes, in a declarative way, what the component is expected to do when it tries to communicate with something outside its boundary.

It’s the moment when we say: “When the component calls this endpoint, with this payload, respond like this.” The important part is that Anticipate is not only about returning predefined responses - it also verifies the interaction: it ensures the expected call was actually made, and that it was made with the correct inputs derived from the arrangement. It includes both the Arrange and Assert aspects of mocking.

That small structural change gives us a clearer lifecycle:

Arrange creates the data and preconditions;
Anticipate defines and validates all external interactions;
Act executes the component;
Assert checks the result.

So the flow becomes: Arrange → Anticipate → Act → Assert.

At this point, you might ask: Doesn’t this just move complexity from one place to another? It could, if we allowed Anticipate to turn into a smart, branching monster. The trap is the same as before: it’s tempting to write anticipation rules like “if this field is true, return success, otherwise return an error.” That kind of logic makes Anticipate behave like a decision engine, and soon you’re back to tests that are difficult to reason about.

The discipline we use is simple: anticipation should be atomic. It should represent one specific expected interaction and one specific response, without internal branching. If you need different outcomes, you don’t implement them as if statements inside a single anticipation. You create individual anticipation scenarios for individual functions.
Yes, this can introduce code duplication. But in this case, duplication isn’t a smell — it’s a boundary. Each scenario becomes an explicit, readable building block: the success path, the “missing field” error, the “unauthorised” response, the timeout, and so on. These blocks are easier to compose, easier to refactor, and harder to couple together accidentally.

In a TypeScript testing context, an Anticipation function looks like this:

Notice how the logic is contained in a single, reusable function that’s defined before the test case. Then we can make as many functions as needed for other scenarios.

This approach allows tests to remain:

Atomic: Tests one thing.
Declarative: The scenario is defined upfront.
Reusable: Anticipations can be used in every test that interacts with that client.

Generators

No “if” statements and code copy-pasting — both lead to too many lines, which quickly become hard to read for humans, but AI handles it well. To improve readability, we propose wrapping object initialisation into generator functions that define all default parameters.
This means you don’t need to specify every field of an object and can focus only on what is essential for the test. With this approach, objects and mocks can be generated directly in the test without adding excessive code.
This makes the code less disruptive and less bulky. For example:

We went further and built the entire generator framework, focusing on making object creation easy, immutable, and predictable, with consistent and repeatable results.

The full framework: AAAAA (the fifth A)

The final 'A' stands for AI. We discovered that by strictly enforcing the 4-stage structure (Arrange, Anticipate, Act, Assert), we inadvertently created a testing style that's surprisingly friendly to AI-powered code generation tools.

The structured, declarative nature of AAAA means the test context is clear, explicit, and segmented. This predictable structure allows tools to generate entire, high-quality tests or complex mock/anticipation stories with minimal hallucination or error.
To ensure maximum AI compatibility and minimal 'mocking hell' recurrence, we enforce a strict set of rules, which are essentially best practices for clean testing.

An example of rules:

Structure: Each test must follow the Arrange → Anticipate → Act → Assert. A test validates exactly one action. What state to set up (Arrange)? What external interactions to simulate (Anticipate)? What function to call (Act)? What results to check (Assert)?

No Logic: Tests must contain no branching or inline logic (if statements, for loops). The fixtures and anticipations fully define the scenario.
We wrote down all our assumptions about how tests should follow AAAA. Then, we described what is good and what is bad, giving examples to help AI. After that, it’s ready and works great in the production code.

Why does this work well with AI?

The AAAA approach encourages a very declarative style: it minimises external dependencies and wraps functions and classes, making tests more self-contained. On one hand, you still need to understand each test, but that understanding requires much less effort because the test carries its own context.
This significantly reduces the amount of context an AI model needs to keep in mind. Each test effectively encapsulates its own setup and assumptions. Of course, the program code still needs to be in context, but that’s unavoidable.
As a result, AI tools are less likely to “guess” missing details and can generate or extend tests with fewer hallucinations. With the right manual, AI can easily write, read, and validate tests, and repetitive changes that may now arise can be handled easily.

Join Bolt

Grow fast, make a global impact, and help make cities for people, not cars. Explore hundreds of open roles on our careers page.

¹ https://martinfowler.com/bliki/GivenWhenThen.html

²https://xp123.com/3a-arrange-act-assert/

³ https://betterprogramming.pub/rethinking-testing-through-declarative-programming-335897703bdd

⁴ https://semaphore.io/blog/aaa-pattern-test-automation

⁵ https://dev.to/leeannamarshall225/bdd-automated-testing-vs-unit-testing-key-differences-explained-43i3

AAAAA Testing: How to make tests AI-friendly

We’re hiring!

Recent posts

Transforming mobility data into urban insights