If you're a software professional in this day and age, you know it's difficult to avoid hearing the terms "agile software development" and "test-driven development." You may even have heard them uttered together in the same sentence. But how often do you examine your deeper understanding of these terms?

We're going to explore what these terms mean and whether or not test-driven development is required to be agile. But before we make that determination, let's define agile and test-driven development.

Agile Defined

Agile software development is a methodology focused on delivering working software in short iterations, with an emphasis on continuous improvement. Gone are the days when the requirements-gathering phase eats up weeks or months (or, gulp, even years) before anyone writes any software. In agile, iterations last a week or two, at which point the team delivers some amount of functional software. Iteration reviews, sometimes called demos, show stakeholders what the team has delivered once an iteration is complete. Retrospectives are also an important concept in agile. During a retrospective, teams can reflect on the previous iteration and generate ideas on how to improve in the future.

Why are the iterations so short? Because the business requirements change. They change, and they change often. If we develop software that no one sees or uses in months, we run the risk of building the wrong thing and misaligning with the business. Showcasing our work to the stakeholders or end users as soon as possible gives us instant feedback. It makes sure we're on the right track. Short iterations also give teams the flexibility to quickly shift towards developing features if the business needs change.

Agile software development teams are composed of team members with different areas of expertise. This means that teams include not only engineers but also business and product owners—and even designers. Typically, team members should be accessible to one another to keep progress moving in the right direction and to reduce roadblocks.

Test-Driven Development Defined

Test-driven development, or TDD, is a software development practice that dictates you write unit tests before you write any production code. TDD follows short cycles in the form of red, green, refactor. When a developer is in a red state, they have a failing test. Congrats—that's the first step! Now only enough production code should be written to make the failing test pass. The cycle moves to the green state when the failing test passes. The final step in the cycle is to refactor the code to make it more understandable and to consolidate ideas.

Software developers new to TDD may feel the overwhelming urge to jump into writing the production code. I found myself in this same boat when I first started learning TDD, but it took practice and a little patience in order to see its benefits.

One of those benefits is a significant increase in code coverage. Because tests are written before any production code, our automated test suite should execute every line of code in our application. If we continually practice TDD, we should see test coverage numbers approaching 100%, giving developers confidence in their changes and in their codebase.

TDD also results in much less code, and the code that remains is cleaner. That's because developers who practice TDD only focus on one small component of a feature at a time. Then, they write only the minimum amount of code to make the test pass. A lot of unnecessary code—maybe a result of a thought process that wasn't quite finished—winds up removed.

Do We Really Need TDD to Practice Agile?

Before I joined a team that practiced TDD, I mostly supported legacy manufacturing and inventory systems. None of these systems had any unit tests whatsoever. And these programs I worked on were important—like the one that controlled the entire flow of inventory. One such application (that I begrudgingly changed on a regular basis) even had an infamous function called update_weight that was over 5,000 lines of code! I knew it was ugly, and I wanted to fix it. However, I'd seen other developers before me introduce bugs by refactoring, which caused major inventory and accounting problems. This created a ton of headaches for those tasked with resolving the problem. And, of course, it wasted a lot of time. Many of these bugs weren't discovered for weeks, and they only surfaced because material wasn't accounted for. I wasn't going to make the same mistakes, so I let the code carry on as it was.

I'm now on an agile team that operates with TDD at its core. We even attribute most of our bug-free success and operating efficiency to it. Because I've had these two very different experiences, I'm a firm believer that TDD makes a huge difference in the agile process. It lets you change the code when you need to, and it helps reduce waste. Let's talk about both of those things in more detail.

Ability to Change

Change was a key word in my definition of agile. In fact, change is core to agile. Agile recognizes that change is going to happen and teams need to be prepared. My previous experience programming without TDD illustrates why one might be reluctant to change code; it's because it was possible you'd introduce bugs. But we as professional developers are paid to change our codebases. The only way to deliver features is by changing our codebase. And by delivering features, we're propelling our team and our product forward.

TDD gives developers the ability to refactor code without fear, due to a powerful test suite. A developer should feel empowered to make refactoring changes, small or large, and not worry about creating problems. After I make a refactoring change, I simply run my test suite to ensure code integrity.

Difficult-to-read, confusing code means that it will take longer to implement changes. Refactoring can lead to code that's easier to understand, which improves its changeability and means you can implement changes faster.

Reducing the time you spend changing code means reducing waste in the entire development process. So as long as we're discussing reasons TDD helps improve upon agile methodologies, let's take a moment to discuss reduced waste as well.

Reduce Waste

A study conducted by Microsoft Research found that TDD resulted in a 40 to 90 percent drop in defect density. This means that developers spend less time researching and fixing bugs and more time writing new code. After all, a large part of agile is reducing the amount of waste by closing the feedback loop. Fewer bugs mean the business has more confidence in the development team and the product during every release.

At my past job managing inventory systems, we developers didn't officially consider ourselves an agile team. But we really were. Our priorities shifted according to the priorities on the plant floor and in the market. The team didn't have daily stand-up meetings, but we also didn't plan our software releases months in advance. We frequently made code changes and deployed those changes to production to deliver the business value. However, because we weren't following test-first practices, we wasted a lot of time investigating and resolving bugs. And it wasn't just that—we were afraid of releasing bugs. Fear of bugs created an atmosphere that promoted code reviews, which requires even more time and coordination. The team could have been operating much more efficiently if we didn't lack confidence in our code changes.

Conclusion? You Want TDD

Based on my previous experiences working in the agile space without TDD, I can't imagine succeeding without it. I even follow TDD practices for my personal projects because I know it will result in cleaner code, fewer bugs, and time saved in the future. I also feel confident in refactoring and leaving cleaner code for developers who follow after me. After all, I want my code to be running long after I've moved on.

I encourage any agile team that wants to improve their entire software development process to seriously consider TDD. Agile teams can definitely operate without TDD, but once the codebase expands, they'll waste more and more time. If, on the other hand, agile software teams want to operate like a well-oiled machine, they'll use TDD to save time and reduce waste.

This post was written by JT Wheeler. JT got his start working as an engineer in the manufacturing industry. From there, he moved on to become a developer at a software consulting firm. He's written software that spans a number of industries ranging from industrial automation to inventory control to financial systems, and he's passionate about learning and teaching new technologies and software practices.