Arrange-Act-Assert is a structure for the body of a single unit test, named by Bill Wake: set up the object under test, perform exactly one action on it, then make claims about the result. It matches the first three phases of Gerard Meszaros' Four-Phase Test and leaves teardown implicit; a second action means a second test.

Arrange-Act-Assert (AAA)

Details

Full Name: Arrange-Act-Assert — three named phases for the body of a single unit test, abbreviated "3A" by the author who named it
Also known as: 3A, the AAA pattern, Setup-Exercise-Verify (the first three phases of Gerard Meszaros' Four-Phase Test), Build-Operate-Check (the same split under different names in Robert C. Martin’s Clean Code)

Core Concepts:

Write the Name Out — the Acronym Points Somewhere Else: "Arrange-Act-Assert" is the anchor. "AAA" is not: it is the standard abbreviation for Authentication, Authorization and Accounting in network access control, and that is what a model retrieves from the three letters alone (see Current Status). Spell it out in prompts, in test comments and in team vocabulary.
Three Phases, One Action: Bill Wake’s own definitions. Arrange: "Set up the object to be tested. We may need to surround the object with collaborators." Act: "Act on the object (through some mutator). You may need to give it parameters." Assert: "Make claims about the object, its collaborators, its parameters, and possibly (rarely!!) global state." The decisive word is one action: a second Act in the same test means a second test.
Origin, Dated by the Author Himself: Wake’s post "3A – Arrange, Act, Assert" is dated 26 April 2011 and says: "I (Bill Wake) observed and named the pattern in 2001." The 2001 date is therefore the author’s own recollection, written down ten years later, not a contemporaneous record.
The Fourth Phase Is the One AAA Drops: Meszaros' Four-Phase Test names "fixture setup, exercise SUT, result verification and fixture teardown". AAA renames the first three and leaves the fourth implicit — "In the fourth phase, we tear down the test fixture to put the world back into the state in which you found it." In a test that touches files, databases, clocks or global state, that omission is yours to fix; AAA will not remind you.
Not the Same Altitude as Given-When-Then: Given-When-Then shapes an acceptance scenario in the language of the domain, written to be read by people who do not read code (gherkin, bdd-given-when-then). Arrange-Act-Assert shapes the body of one unit test in code. The structures are parallel; the audience, the artifact and the level are not. Use Given-When-Then to agree on behaviour, Arrange-Act-Assert to lay out the test that checks it.
A Swollen Arrange Is a Diagnosis: When the Arrange block dwarfs Act and Assert, the test is telling you something about the design: too many collaborators, a constructor that demands irrelevant data, hidden dependencies. The two standard remedies are test doubles (test-double-meszaros) and builders that hide safe defaults (test-data-builder).
Marking the Phases Is a Discipline, Not Decoration: Meszaros' argument for writing the phases down: "Using comments to mark the phases of a Four-Phase Test is a good source of self-discipline in that it makes it very obvious when our tests are not Single Condition Tests."

When to Use:

Asking for unit tests and wanting one behaviour per test instead of a single method that calls six things and asserts on all of them
Reviewing tests: the three phases make it visible where a failure comes from — bad setup, wrong call, or wrong expectation
Teaching test structure, where the named phases give beginners a shape to fill
Refactoring a test suite whose Arrange sections have grown out of control, as the entry point to builders and test doubles
Next to bdd-given-when-then when the team needs both levels and keeps confusing them

Common Misunderstandings:

❌ "AAA" — the bare acronym retrieves Authentication, Authorization and Accounting, not testing; the written-out name is the anchor
❌ "Arrange-Act-Assert means exactly one assertion per test" — contested, and Wake himself writes of that guideline: "I don’t follow that guideline too closely." See Criticism
❌ "It is just Given-When-Then for programmers" — same shape, different altitude and different audience
❌ "Three phases cover every test" — teardown is missing by construction, and shared setup and multi-step scenarios need adaptations
❌ "The comments are the pattern" — the single Act is the pattern; the comments only make a violation obvious
✓ "One action per test, with setup and expectation visibly separated from it" — accurate, and the part worth insisting on

Criticism:

The strict reading — one assertion per test — is contested, and the pattern’s own author is on the permissive side. Dave Astels made the case for the rule in "One Assertion Per Test" (23 February 2004), arguing that tests are specifications of behaviour and that the rule keeps you working in "the smallest steps possible, both for the finest-grained long-term verification, and for the most flexible design evolution"; where a test wants several assertions, he decomposes it into separate fixtures instead. Wake answers eleven years later in "Multiple Asserts Are OK": "I first heard the 'one assert per test' idea years ago from Dave Astels, and others have picked it up since then", and "Multiple assertions can be a sign of trouble in tests. But as you’ll see by the end, some situations make good use of groups of assertions." Astels, "One Assertion Per Test", Artima, 23 February 2004 and Wake, "Multiple Asserts Are OK", Industrial Logic, 29 September 2015. Anyone who cites "AAA" as authority for a hard one-assert rule is citing a position its author declined to hold.
The three phases do not fit every test shape, and the teaching literature says so. The Freie Universität Berlin’s AG Software Engineering, in the course material for its Programmierpraktikum (Sommersemester 2026), names two cases where the plain structure breaks down: "Viele Tests teilen dasselbe aufwändige Setup — Kopieren kostet Zeit und erzeugt Fehlerquellen", and "Ein Testszenario besteht aus mehreren aufeinander aufbauenden Schritten, deren Zwischenzustände jeweils überprüft werden sollen." Their remedies are helper functions for the shared Arrange and an A-AA-AA shape with several Act/Assert cycles. The page presents these as adaptations rather than as grounds to abandon the pattern. AG Software Engineering, FU Berlin, "Das AAA-Muster: Strukturierte Unit-Tests".
Asserting the precondition before acting is the other standing patch. "Arrange-Assert-Act-Assert" adds a check that the setup really produced the state the test assumes, so a failure cannot be silently blamed on the action. Wake shows the shape himself in "Multiple Asserts Are OK": "// arrange / set up something hairy / // assert on setup / assert setup looks right / // act / probe a behavior / // assert / verify its consequences". The cost is that the test now has two kinds of assertion in it, and the reader has to tell them apart.
Teardown is a real gap, not a simplification. Meszaros keeps the fourth phase for a reason — a test that does not put the world back breaks the next one — and AAA’s three names give no place to put it. Meszaros, "Four-Phase Test", xunitpatterns.com (the site serves plain HTTP only).

Current Status:

The bare acronym anchors a different field entirely. Asked "What is AAA?" in a clean room on claude-haiku-4-5 (2026-10-03), the weak tier answered: "AAA stands for Authentication, Authorization, and Accounting, a security framework commonly used in networking and access control", went on through RADIUS and TACACS+, and mentioned the American Automobile Association before any testing sense. The written-out name is therefore the anchor; the acronym alone is not.
The prior behind the full name is dense enough to surface unprompted. On a test-readability task measured the same day, the no-anchor baseline reached Arrange-Act-Assert by itself in two of four runs. Naming it makes the structure explicit and settles the one-assert question; it does not introduce an unfamiliar idea.