When developers discuss automated testing, the conversation often begins and ends with code coverage. “We need to make sure our code works.” However, over time, I’ve come to realize that this framing overlooks the true value of tests. Tests are not just safety nets; they’re living documentation of the business.
In my talk, “Improving Development with Context-Based Testing,” I demonstrated how shifting from a traditional one-test-fixture-per-class approach to context-based testing makes tests easier to read, write, and maintain. More importantly, it makes them meaningful to both developers and the business.
I wrote more about this in an earlier blog post, Context-Based Testing. The article introduces the practice at a high level, breaking away from thinking of tests as a validation of classes and instead seeing them as specifications of business features. What I would like to add here is more of the why—why this approach has been so practical in real-world projects.
The Problem with the Typical Approach
Most of us learn testing with the Arrange–Act–Assert pattern. We write one giant test file for each class. Soon, those files balloon into hundreds or even thousands of lines, with repeated setup code, copy–paste test cases, and unreadable mocks. When tests become this messy, they stop being maintained. A bug fix that requires only two lines of code suddenly needs 50 lines of test changes. Under deadline pressure, tests are skipped.
I’ve been there. I bet you have, too.
From AAA to Given–When–Then
The turning point for me was refactoring tests to read in plain English:
Given an account with initial balance of 50
And line of credit of 100
When withdrawing 80
Then the new account balance should be 0
And the new line of credit balance should be 70That’s much clearer than a pile of setup and assertion code. Non-technical stakeholders can follow along. Now we’re not just writing tests to make sure code works; we’re codifying business behavior.
Organizing by Context, Not by Class
Context-based testing takes this a step further. Instead of writing tests grouped by implementation (e.g., BankAccountTests.cs), we organize by business activity: Depositing, Withdrawing, Transferring Funds.
Each file describes a single context, like Withdrawing with Insufficient Funds or Depositing a Negative Amount. Inside, tests remain short and focused. Adding a new scenario is as easy as creating a new context file. Reading the test suite feels like reading business rules, not plumbing code.
This also keeps implementation flexible. Maybe withdrawals are handled by one class today and a service tomorrow. Our tests don’t change, because they’re tied to behavior, not plumbing.
Collaboration Through Tests
This shift also changes conversations. Instead of asking, “Does this code work?” we ask, “Does this behavior reflect the business rules we agreed on?” When a product owner or business analyst sees the phrases in the earlier example, they know we’ve been listening.
Nobody calls a business and says, “I’d like to delete my order.” You cancel an order. The words matter. The same principle applies to our code. Using the right business terms in tests helps avoid confusion later and prevents us from implementing the wrong thing.
Beyond the Business
Not every test is business-facing. Some are deeply technical. But the same principles apply. Even when parsing a file format, I still write: “Given this input, when parsing, then the output should be …” Organizing by context clarifies intent, regardless of the audience.
Why It Matters
Context-based testing pays dividends:
- Readability: Tests are short, focused, and written in business terms.
- Maintainability: Refactoring implementation doesn’t break specs.
- Collaboration: Business and devs can discuss the same artifacts.
- Trust: Stakeholders see that their language, not just code, drives development.
For me, that’s the real value of automated testing. Not just code coverage, but confidence and clarity.
If you’d like the introductory version of this story, check out my earlier blog post here. For more in-depth, watch a complete presentation on this topic here:
Leave a Reply