Testing in Agile: From Afterthought to an Integral Part

For much of my early career, testing was an afterthought. I would write code, click around the application, and if it didn’t blow up, I would move on. Testing felt like a chore; something you did at the end. Over the years, though, I’ve learned that testing isn’t just a technical safety net. It’s a catalyst for better code, clearer thinking, and stronger collaboration across the whole team.

From Manual to Automated

My first exposure to testing was similar to that of many developers: manual. Compile the app, launch it, log in (after mistyping your password a few times), navigate through the menus, enter data, and hope the right thing happens. It was repetitive and error‑prone. Worse, it slowed me down.

Eventually, I began extracting logic from the UI into separate classes. That allowed me to write little console apps that exercised the logic directly, providing primitive automated tests. Then, around 2003, I attended a conference session on unit testing. Suddenly, those console apps could be formalized into repeatable, automated checks with test frameworks and test runners. That was a turning point.

Beyond Training Wheels

Most developers are introduced to testing through the Arrange‑Act‑Assert (AAA) pattern. It’s a great starting point, but it’s also just that: training wheels. Too often, I meet developers who have been writing tests for a decade but are still writing “year one” tests. AAA helps you get started, but eventually you need to evolve.

I hit the pitfalls that come with stopping there:

Writing hundreds of “unit tests” that were really brittle integration tests.
Chasing arbitrary code coverage percentages.
Copy‑pasting giant test methods full of mocks, stubs, and setup code that nobody wanted to maintain.

The result? Tests that existed on paper but weren’t helping the business or the team.

Thinking in Behavior, Not Implementation

The breakthrough came when I adopted practices such as TDD (Test-Driven Development), BDD (Behavior-Driven Development), and DDD (Domain-Driven Design). Instead of thinking in terms of database tables or UI controls, I started thinking in terms of behavior and business value.

That shift changed how I wrote tests. Rather than:

[Fact]
public void TestMethod1()
{
    // Arrange
    var account = new Account(50M, 100M);

    // Act
    account.Withdraw(80M);

    // Assert
    Assert.Equal(0M, account.Balance);
    Assert.Equal(70M, account.LineOfCreditBalance);
}

I began writing:

[Fact]
public void withdraw_within_line_of_credit()
{
    given_account_with(InitialBalance: 50M, lineOfCredit: 100M);
    when_withdrawing(80M);
    then_new_account_balance_should_be(0M);
    then_new_line_of_credit_balance_should_be(70M);
}

The same code is underneath, but now the test reads like a specification that anyone can understand. Product owners, business analysts, and QA folks could read it and join the conversation. Tests stopped being just “tests” and became living documentation.

The Language of Collaboration

This is the most essential lesson that testing has taught me: the importance of better collaboration. Developers tend to hide in technical jargon, but testing practices can force us to articulate behavior in plain English. They make us slow down and ask:

What problem are we really solving?
What does success look like for the business?
What scenarios matter most?

For example, instead of a user story that says:

As the system
I want to remove duplicate entries from the database
So that I don’t have duplicates

We reframe it as:

As a marketing manager
I want to send direct mail with no duplicate addresses
So that I save on mailing costs.

The second version explains why the feature is important. Flip it further:

In order to save on mailing costs
As a marketing manager
I want to send direct mail with no duplicate addresses

Start with the “why,” and suddenly everyone, business and technical, has a shared understanding of value.

No Given‑When‑Then, No Code

That’s why I often say: No Given‑When‑Then, No Code.

If you can’t express a scenario in plain language, you’re not ready to write code.

Writing and reading code is expensive; writing and reading English is cheap.

Clear scenarios save hours of rework later.

Testing as a Unifier

Over time, I’ve seen how these practices change the dynamic of a team:

Developers stop dreading tests because they’re easier to read and maintain.
QA professionals are no longer an afterthought; they contribute from day one.
Product owners see their language reflected in the code and gain trust in the process.

At its best, testing isn’t just about preventing bugs. It’s about making sure we’re building the right thing, the right way, together.

Watch a complete presentation on this topic here:

Claudio Lassala's Blog