Claudio Lassala's Blog

Most developers who practice Test-Driven Development (TDD) are familiar with the cycle: Red → Green → Refactor. You start with a failing test (red), write just enough code to make it pass (green), and then refactor. Simple, right? Except there’s a catch: many developers skip the most important part when it comes to long-term maintainability: they don’t refactor the test code.

Too often, we clean up the production code but leave test code messy, verbose, and repetitive. Over time, tests become cluttered, hard to understand, and painful to maintain. Eventually, teams lose trust in their test suite and abandon it altogether. But it doesn’t have to be this way.

Why Refactor Test Code?

Tests are not “just test code.” They are documentation of the system’s behavior. Better yet, they can document our understanding of the problems the system solves. If tests are unreadable, they lose their value as communication tools. A good test should:

• Be easy to read and understand, even for non-technical stakeholders.
• Express behavior rather than implementation details.
• Encourage collaboration and conversations about the domain.

From Arrange-Act-Assert to Given-When-Then

Most of us learn the Arrange-Act-Assert (AAA) pattern on day one. It’s a good start, but ten years later, many developers are still writing tests the same way. AAA is training wheels. At some point, we should grow into a more expressive structure: Given-When-Then (GWT).

• Given establishes the context.
• When describes the action taken or the event that happened.
• Then describes the expected outcome.

Instead of this:

// Arrange
var pizzaMaker = new PizzaMaker();
// Act
var pizza = pizzaMaker.MakeMeatLover();
// Assert
Assert.Contains(pizza.Toppings, t => t.Name == "cheese");
Assert.Contains(pizza.Toppings, t => t.Name == "sausage");
Assert.Contains(pizza.Toppings, t => t.Name == "bacon");
Assert.Contains(pizza.Toppings, t => t.Name == "ham");
Assert.Contains(pizza.Toppings, t => t.Name == "pepperoni");

We can write this:

given_a_pizza_maker();
when_meatlover_pizza_is_made();
then_only_the_following_toppings_are_expected("cheese", "sausage", "bacon", "ham", "pepperoni");

The difference is more than cosmetic. The second example:

• Reads like English.
• Focuses on behavior, not implementation.
• Can be shared with business stakeholders.

Refactoring for Clarity

When you see repeated patterns (walls of assertions, duplicated setup code, copy-paste variations) that’s a code smell. Just like production code, test code benefits from:

• Abstractions (helpers, factories, reusable Givens).
• Custom matchers that speak the business language.
• Expressive naming that communicates intent.

For example, instead of:

expect(result.hasOwnProperty("draftId")).toBe(false);
expect(result.hasOwnProperty("orderHeader")).toBe(true);

You can write:

expect(result).toLackProperties(["draftId"]);
expect(result).toHaveProperties(["orderHeader"]);

By extending the assertion library with domain-specific helpers, tests become shorter, clearer, and easier to understand.

Behavior-Driven Development in Practice

This approach naturally blends with Behavior-Driven Development (BDD). You don’t need special tools like Cucumber or SpecFlow to start. You just need the mindset:

• Write tests in the language of the business.
• Use tests as a way to explore and validate assumptions.
• Let the tests drive the design of your APIs.

For example:

[Fact]
public void Brazilian_pizza_should_have_a_lot_of_meat_and_cheese()
{
    given_a_pizza_maker();
    when_brazilian_pizza_is_made();
    then_only_the_following_toppings_are_expected("beef", "ham", "bacon", "extra cheese");
}

Even if the “Brazilian Pizza” requirement is new, this test captures the business expectation before a single line of production code is written.

And yes, the Brazilian pizza example comes from real life: I like meat and I like cheese! Bringing that cultural flavor into the tests not only makes the example more fun, but it also reminds us to write tests that are about describing intent in human terms. Whether the requirement comes from a product owner or a hungry customer, the goal is the same: clarity of expectation.

Tests as Collaboration Tools

Readable tests are not just for developers. They become a shared artifact for:

• Product owners validating features.
• QA engineers exploring edge cases.
• Developers reasoning about design decisions.

When your test suite reads like English, you invite the whole team into the conversation.

The Takeaway

Refactoring isn’t just for production code. Clean, expressive test code makes it easier to:

• Maintain a healthy codebase.
• Refactor implementation safely.
• Collaborate across roles.

So the next time you think you’re “done” because your tests are passing, take one more step: refactor your test code. Make it readable. Make it meaningful. Because tests aren’t just for machines: they’re for people.

You can watch a complete recording of a presentation I gave on this topic here: