For several years I had heard and read about an “extreme” way of writing and testing applications. The concept was radical, but simple. Before you implement a single piece of functionality, you write a test that proves your application doesn’t yet have said functionality. Run the test and watch it fail. Would you expect anything different? Then, you implement the functionality and re-run your test, expecting it to pass. Really?

Really. This software development methodology is known as “test driven development”, or TDD for short. For years I had heard about TDD, but to me it was like the 50-foot shark or the unicorn – many had claimed to experience it, but I had never seen it first hand or met anyone who lived to tell about it.

Three years ago, my career took a turn for the better, where I had the opportunity – no, blessing – to be exposed to test driven development in practice. Since, I have been not only a fan, but an advocate. Developers practicing TDD have their own reasons for loving it, as do I.

My applications are self-documenting.

I’m a developer, not a technical writer. I don’t enjoy writing documentation. As a matter of fact, in 15 years I have never met a developer that does.

Here’s the problem with traditional documentation – it doesn’t evolve gracefully. Can you update documentation as the application changes? Sure. But the reality is that documentation usually goes stale rather quickly and no one really wants to maintain it.

Writing tests that describe what your application should do is the best form of documentation. Another developer looking at my code (maybe even myself in the future) should be able to easily read through my tests and understand exactly what my application is intended to do, and how it is supposed to behave.

When my application needs to change, I write new tests that describe the functionality I’m adding or changing, before I implement the functionality. This ensures that as my application evolves, so does the documentation. My tests are all the documentation my application needs.

I write more readable code.

No one sets out to create big, unwieldy methods, but we’ve all ended up there. Maybe it’s over-engineering, maybe it’s laziness, or maybe it’s just too many different hands in the same codebase.

The practice of writing tests first helps you think about the problem, rather than the solution. It also forces you to write code that is easily tested. Big methods are difficult to test, and cumbersome to maintain. When code evolves as a result of being driven by tests, that code will be more terse, tidy, and easy to read. Your fellow developers – and even your future self – will thank you for it.

I’m a better developer.

Developers today are expected to be more in tune with the business. More and more companies are gravitating towards Agile methodologies of building software. As developers, we need to connect more with the business needs.

Writing tests that express what the business needs allows the business to have embedded representation in the application. The requirements are “baked” in to the application, and evolve as the business needs evolve.

Quality is built right in to my code.

I’m one of those people that pays attention when my car starts up. I listen and watch for all the automated system checks it performs – airbags, oil pressure, tire pressure, and many other things I am unaware of. I consider that to be an important thing the car does. I think it’s crucial that the engineers of my car built in a way for the car to test itself. After all, who better knows how my car should operate than the engineers who built it?

Software should be no different. Writing applications by supplying tests that prove your application behaves exactly as designed builds quality right into your code. Simply put, testing should be in your application’s DNA.

I code with joy, not fear.

There was a time when making significant changes to a big application caused a great deal of angst. The bigger the application got, the less comfortable I felt making changes to it. Evolving software through iterative tests and refactoring creates a development experience I have never known before.

I now write code that is easy to maintain, easy to test, and a joy to write. I no longer worry about what I might break if I make a significant change. I am free to refactor to my heart’s content. I have been writing code for 15 years, but it wasn’t until I discovered test driven development that I began building software – and loving it.