Test-Driven-Development, Put Plainly

Every industry has its buzz-word jargon that is meant to make your resume search-engine-optimized and your speeches TEDx worthy. These phrases often point to an idea with merit, but the packaging makes me want to projectile vomit. If a man in a suit starts talking about “synergy” or being a “thought partner,” all I see is Jack Donaghy filling in his Six Sigma Wheel of Domination, and all I feel is the bile rising.

My weak stomach aside, it is important to know what tech’s keywords are and—if they’re worthwhile—how to implement the ideas. Test-Drive-Development, or TDD, is worthwhile. So, what is it, why does it matter, and how do you do it?

What is TDD?

TDD is the practice of building and running tests for your program before you write the code that you want to test. That means that the first time you run the tests, they will fail. This process ensures that you think about the purpose of all the code you write, which should cut out redundant or unnecessary code and make what you do write clearer.

As a side note, when researching TDD you are bound to come across Agile Software Development. In short, Agile is a group of protocols that help tech businesses run smoothly. Other Agile practices include User Stories, Retrospectives, Scrum, and Stand-ups.

Why does TDD matter?

Frankly, it matters because people think it matters, which means you probably need it to get a job. The only data I found to support TDD was on a blog post by Hillel Wayne who quotes a study that suggests “TDD projects had roughly a 60% decrease in defect density.” So TDD may lead to a decrease in bugs and an increase in quality.

However, even Agile Alliance’s website says, “although empirical research has so far failed to confirm this, veteran practitioners report that TDD leads to improved design qualities in the code…” When your lead evangelist says, “I can’t prove it, but listen to what these people have to say!” you’re as good as an as-seen-on-tv product no one asked for.

How to use TDD

The framework you write your tests in depends on the language you use; some frameworks include Mocha, Capybara, Cucumber, Konacha, and Poltergeist. Deciding which to use and how to write the tests is another topic in and of itself. Regardless of which language you write in, there are five steps to TDD:

1. Write a test for your program. In order to write tests, you have to know what data types you will pass into methods, as well as what type of data you expect it to return.
2. Run (and fail) the tests. If the tests don’t fail, they’re not checking what you wanted them to check. If they do fail, you are able to observe how your program behaves when it fails.
3. Write the code in your program needed to pass the first test. Write as little as possible to get it to pass.
4. Keep coding until all of the tests pass.
5. Refactor as needed.

While the evidence for the efficacy of TDD is not strong, it is important to be comfortable with the protocol, and hey, maybe you’ll avoid writing buggy code this way, too.