Test Driven Development (TDD): Killing Bugs Before Day Zero

Writing software is hard. Well-crafted software takes dedication, thoughtfulness, and a willingness to unburden future developers.

And it takes tests. Lots of tests.

Any software company that plans on releasing its creation to the bug-thirsty masses will put that product through rigorous testing before it goes live. At many companies, bugs are identified by a test team to be squashed by the "incompetent" developers that let them slip in. Then after many weeks (or years for the unlucky few), D-day arrives, the product is deployed, and… you guessed it. Bugs. Crawling around in the lap of the users.

Sound familiar?

Though that may seem like the inescapable reality of software development, it is not the only path to profitability. It is possible to deliver a bug-free software application on day 1.

You heard me right. No bugs. None to identify, none to sit in a GitLab issue for some future release, absolutely 0.

But how?

Developers must transition from a manufacturing line mentality to a craftsman mentality.

The craft of writing software is as rooted in creativity as it is in analytic problem-solving.

• Favoring the creative side yields software that no one asked for - most companies won't allow this to happen past the prototype stage because they can't afford to delay launching the product indefinitely.
• Favoring the analytical side creates software that gets the job done but has to be almost entirely rewritten to add new features. This is more common, and development that was fast at first will slow down until it comes to a crawl.

Craftsmanship is born from both art and science. Careful processes that are finely tuned and strictly followed produce the beautiful software we all want, while still delivering the guaranteed, rapid results that the company executives demand.

Test Driven Development (TDD) is a key process in this craft.

Here are my top reasons for "why TDD", in no particular order:

1. You're going to write tests anyway.

Even if no one in your company writes a single automated test, every single developer is at least going to the command line and testing out the code they've written. If you're going to write it once, why not write it in a script (test) so you can run it more than once? You'll find your speed will always increase when you write tests first.

2. Get the right feedback early.

When you write a test after the code is written, you focus on "self-validation", ensuring the code works how you said it did - this is most clearly evident in heavy mocking. When you write a test before the code, you focus on how the API should fulfill the business requirements.

3. Know the goal before you write the plan.

Wrong plan, wrong direction, wrong product. We all know this, and yet we still insist on jumping down the code rabbit hole for hours before finally realizing that we fixed everything but what was originally asked for. Start with a test, make it pass, and refactor. Then repeat.

4. Build software, not hardware - the difference is trust.

What makes a piece of code hard to change (i.e., it's no longer soft)? Fear that changing it will have unintended consequences. A lack of tests brings about this fear. Writing tests after the fact makes it more likely your code is harder to write tests for, which makes your tests harder to write. That means you're more likely to skip tests in some instances, which leads to distrust of the tests, and then fear of changing the code.

TDD isn't for everyone. It isn't for your manager, who just needs you to get your job done. It isn't for your investors that need that next product out tomorrow.

TDD is for the future developers that will touch your code, whether that developer is you today and tomorrow or the next guy in a month or a year from now. It's also for the customers - they may never see the tests, but they will see the bugs that were missed because they weren't caught by the testing team.

Be a craftsman. Catch your bugs before someone else has to by writing tests first.