A colleague once told me he’d developed a mixed approach to testing: Given-When-Then (GWT) for some tests, Arrange-Act-Assert (AAA) for others. His rationale made sense at first: developer-oriented aspects should stay in a developer-oriented format.
I used to think the same way. But I switched to GWT across the board a long time ago, and here’s why: I like reading specs in English. It keeps the conversation accessible to everyone without the constant mental gear-shifting between languages and contexts.
The Real Value: Conversation, Not Format
GWT shines brightest in acceptance criteria. One set of Given-When-Thens per scenario. Use them to explore and understand a story’s purpose and expectations before anyone writes code.
Whether those GWTs become automated tests, and what kind of tests, doesn’t matter at this stage. What matters is the conversation they enable. They create a shared vocabulary that product owners, testers, and developers can all speak fluently.
Apply It Everywhere
Once you’ve used GWT to clarify the story, keep using it:
-
End-to-end tests? Use GWT.
-
UI component specs? Use GWT.
-
API specs? Use GWT.
-
Business rules? Use GWT.
-
Validations? Queries? You guessed it—use GWT.
The pattern holds because GWT describes what is expected in each case. When we look at those specs, we find our whats immediately. When we need to understand the how, we can dive into the implementation. But often, we don’t need to see how it works. We just need to know what it does.
The Context Switch Tax
Here’s what I’ve noticed: if two developers are reviewing unit tests together, they’re still having a conversation in English. But when they’re reading if (whatever == 10) on the screen, that’s a version of English mixed with technical elements that pull them further from the ultimate goal: the value that code brings to the business.
Every time we switch from natural language to code syntax and back, we pay a small tax. It adds up.
Tests vs. Specs
Years ago, I wrote about why I write tests. My answer used to be “I write tests to make sure my code works” and “it allows me to refactor my code.” But bugs still showed up, and other developers couldn’t understand my tests.
The shift came when I stopped making it about me. I’m not writing tests to make sure the code works. I’m writing specs that describe what we get from the implementation: what the business needs, what the team understands, and what value we’re delivering.
That reframing shifts the conversation. A test feels like verification after the fact. A spec feels like a contract written before the fact, a clear statement of intent that guides the implementation.
GWT makes that intent readable to everyone, not just the person who wrote the code. It’s doing it for you, not for me.
What I Notice
The more I use GWT everywhere, the less I have to translate between different mental models. The acceptance criteria look like the E2E tests, which look like the integration tests, which look like the unit tests. The language is consistent all the way down.
And when someone asks, “What does this verify?” I can point to the Given-When-Then and answer in plain English, without needing to parse code first.
It’s a small thing. But small things compound.
Leave a Reply