What Is Test Driven Development (TDD) And Why You Should Use It
The purpose of this post is to introduce some of the many concepts of test-driven development (TDD) that a developer would need to know to get started. This guide should not be considered all-encompassing for developers. That means that if you know absolutely nothing about TDD before starting this guide, you will be briefly introduced into TDD by the end of the post.
The History of TDD
Before we jump into the process of TDD it’s helpful to look at how we arrived at TDD. If we know how much better TDD is than what we used to do, it’s easier to get onboard with the TDD process. This can be especially helpful when you first start practicing TDD and you feel like your development process is taking much longer than it used to.
Early on, the software design process was similar to the manufacturing process: requirements were written up in their entirety, approved by everyone involved, passed to the development team who wrote all the code necessary to satisfy those requirements, then the code was passed to a Quality Assurance (QA) team who tested the code to make sure it satisfied the requirements completely. Over time we came to realize that this process, while it may have been great for manufacturing, really didn’t fit the software development process. Each step having to be completed before the next step can be started – a process commonly referred to as Waterfall Development – doesn’t work in the software development world for a few reasons.
Going From Waterfall to Agile
The world of software moves quickly and new technologies and methods crop up constantly. When we use the Waterfall Development methodology we’re bound to what was decided in the requirements gathering phase. We might have some wiggle room when it comes to which language to use or which frameworks or libraries we want to implement once we’ve started writing our code, but we’re forced to complete features that were conceived before development started. Once we complete the coding phase and we pass the product to the QA team, the development team sometimes finds themselves sitting around waiting for QA to find a defect (a “bug”). Sometimes those bugs are actually issues that should have been discovered during the requirements phase. When QA finds bugs they are costly to fix since the entire monolithic product has been completed before QA ever got to take a look at it.
This is where Agile development methodologies come into play. In 2001 the Agile Manifesto was published, which advocates many changes to the overall software development process. The Agile Manifesto, and the Twelve Principles of Agile Software, focus on iterative development and delivery of small pieces of working software. In order to do that we can’t wait for all of the requirements of the system to be ready before we start development. It also means we can’t develop our code in isolation from the QA team. Often, the QA process is brought into the development process and the QA team works closely with developers to test the small pieces of software as they’re being developed.
Taking Lessons From A Legend
While the Agile manifesto specified some general ideas about software development, it isn’t itself a development methodology. Instead, it gave rise to several methodologies that adhere to the Agile principles. One of those methodologies is called Extreme Programming (XP), which really introduced and heavily favors unit testing. Unit testing as a process means that the developers writing the code will also write other code that tests their code. This changed the way we thought of the QA process so that quality is no longer the responsibility of a separate QA team. Rather the quality of the software is built in and guaranteed – to a degree – by the developer who writes the code, but before anyone tests it to make sure it works.
TDD is an extension of unit testing, “rediscovered” by Kent Beck (creator of XP and original signatory of the Agile Manifesto) from “an ancient book” about programming. The idea in the “ancient book” was to define the expected outputs, write the code, then compare the actual outputs to the expected outputs. This boils down to writing code that implements the requirements provided, but without writing code to meet requirements that were not defined.
"If you're happy slamming some code together that more or less works and you're happy never looking at the result again, TDD is not for you." – Kent Beck
Unit testing is the process of writing code that tests other code at the smallest possible level. So unit tests must be code. This makes sense when you consider that the suite of tests must be run frequently. If we dedicated a person to running an entire suite of tests every time we made a change, we’d be wasting valuable time to do something that can – and must – be automated.
Test Driven Development Is A Discipline
This is a very brief introduction. There is much more to say about TDD such as inversion control, dependency injection, unit testing, automation, refactoring, and more. TDD may seem like something that will slow down your code development, and at first it may. But in the long-run, you will save time and energy by writing clean and concise code.
Andrew Webster is a software extraordinaire who loves to write code that is clean, testable, and stable. He is a Certified Scrum Master, was a Co-Founder of a tech startup, and worked for one of the largest software consulting companies. You can find him on LinkedIn here.