If you’ve ever taken a Codecademy course, you’re familiar with the succinct, detailed instructions at each step of our coding exercises.
These instructions anticipate the most important question anyone will have—What do I do next?—and provide the answer in clear, digestible lines of text.
Unfortunately, like a baby bird must leave its nest, so too must learners leave the Codecademy support system and code on their own.
What if there was a way to ensure that you’ll always have the answer to “What code do I write next?” well after you’ve left the “nest”?
Enter Test-Driven Development
Test-driven development (TDD) is an approach to programming that, somewhat counterintuitively, encourages developers to write tests of their code before actually writing the code itself.
Think of test-driven development as a way to turn your code into an instruction manual for itself. The goal of software tests is to catch any errors before making that software widely available. By writing tests first, you’re laying out a detailed roadmap for what an ideal version of your code is supposed to accomplish. You let the program tell you what to write next.
Obviously, writing a test before actually writing the production code means that the test is bound to fail. That’s the whole point—a well-written test that fails surfaces an error message explaining what went wrong. And that's the brilliance of test-driven development. It takes something that can be discouraging and turns it into a clear directive for what to add to your program next.
Let’s say I was writing a web app that allowed users to input a username in a web browser and then click a “submit” button. There’s no one answer for what my first step should be, but in this case I'll start by creating the “submit” button.
The Codecademy curriculum team might give me clear, step-by-step instructions on how to begin building the frame of the button, but I’m not sure how those directions came to be. The next time I want to create a “submit” button, I’m on my own.
From here, I can lean on TDD. If I first write a test that checks if a functional “submit” button exists, my “instructions” would be a series of error messages from that test, stepping stones from the idea of a button to the real thing. Best of all, once my test returns no errors, I would be certain that the button actually worked.
Companies that use Test-Driven Development
When people are introduced to the concept of test-driven development, a common concern is that writing tests for every feature of a program is inefficient. Why invest so much time in writing tests when I can troubleshoot later? But you wouldn't skip tying your shoes for the sake of getting out of the front door faster, and you shouldn't let hastiness be the reason you skip testing either.
Joe Birch, a Senior Android Engineer at Buffer, writes about his team’s testing practices. When I asked him about common misconceptions around TDD, he told me that the practice has actually reduced development time for his team:
"Following TDD has not only allowed us to write simpler, more understandable code but has allowed us to think more about what we are implementing before actually implementing it. This extra space to think, allows us to understand and test for the different logical paths before getting caught up in implementation details. This, in turn, helps to reduce development time by creating something less error-prone from the start."
The Buffer team’s experience is not unique. I asked engineering leaders at several other major tech companies to explain how their teams approach testing, and their responses made it clear to me that TDD is not just a theoretical ideal—it’s a real approach that is currently supporting much of the tech I run every day.
Nitzan Blouin, a Director of Engineering at Spotify, faced a challenge far bigger than implementing a suite of software test into a massive existing code architecture. She had to introduce a culture of testing within an engineering team that already served millions of listeners. To solve this problem, she implemented a gamified, multi-step program for getting teams to improve their testing practices called TC4D.
Nitzan emphasized that tested code saves time for teams when it comes time to iterate on existing code:
"Many mistake an investment in quality as something that lengthens the development process. At Spotify, we know that shipping high-quality code enables speed of iteration. TC4D is one way to achieve this goal," said Nitzan.
Every day, millions of people open Spotify on a device of their choosing, accessing music in radically different ways. That’s plenty of opportunities for something to break, or for code to be accessed in a way that no engineering team could perfectly foresee.
For this reason, software like Spotify is like a living organism. There’s a constant need to adjust and improve, and the clear roadmap that test-driven development provides makes it easy to return to code later and do just that.
This is a key component in how Alex Clark, a Curriculum Developer here at Codecademy, thinks about TDD. Alex played an instrumental role in bringing our Test-Driven Development Pro Intensive to life, along with the team at thoughtbot. When I spoke to him about TDD, he honed in the readability advantage:
“If you’re doing test-driven development well, you’ll never write comments in your code because your tests are a form of documentation for how your program should work,” Alex said.
Even after thoroughly tested features are launched, there’s a constant need to return to those tests as new features are added. This is true for Arylee McSweaney who manages Test Engineering and Strategy at Etsy.
Sellers and buyers alike rely on the Etsy’s code to work as expected, and like Spotify, each action and transaction presents an opportunity for something to go wrong. As a user base grows, having high test coverage—the proportion of a program’s code that is accessed by its test suite—is critical.
“At Etsy, we find that a focus on test automation yields many business benefits. Test automation helps Etsy to increase engineering productivity, improve code quality and increase confidence in the features launched to the site. These benefits translate to a more robust platform for Etsy sellers and a stronger user experience for buyers on the site.”
Etsy’s user base is bigger than most companies, but even for a smaller startup that plans to grow, building a robust testing suite and automating it will allow that scaling process happen smoothly.
These industry leaders paint a clear picture of how test-driven development improves the quality of the code written across their teams and team efficiency in general.
But what if your code doesn’t have to serve millions of people every day? And what if you’re the only person writing it? Does it still make sense for a freelancer, founder, or student to invest their time in writing a full testing suite first?
Test-Driven Development for the Individual
While test-driven development serves Spotify, Etsy, and other Goliaths well, it can be just as useful for junior developers trying to land a job, smaller startups looking to scale, or founders looking to build their product and wondering where to start.
Many grads coming out of bootcamps can write good code. However, when it comes time to interview for a job, TDD can help you stand out.
"When someone writes tests during an interview, or even just a few lines of code below their work to make sure that their code is working, I am always impressed. This means they are making sure their code works every step of the way. I've also noticed that interview candidates who test their code have fewer syntactical errors," said Lydia Stepanek, a software engineer at Codecademy.
This sentiment is mirrored by Robert “Uncle Bob” Martin. Uncle Bob is a software engineer and author who has been writing about the benefits of test-driven development for as long as the concept has had a name.
"The regular practice of test-driven development will help you to increase your accuracy and productivity; and will greatly enhance the confidence you have in the code you produce," he said.
Notice the singular pronouns he used—no matter the scale, and no matter the purpose, TDD can be the starting point for efficient, readable code that scales up.
The efficiency and protections afforded by TDD are especially important for lean startups hoping to make it. Though they take steps to prevent against them, Spotify and Etsy can afford a mistake slipping by here and there. A seed-stage startup can’t. By eschewing a full testing suite, small startups aren’t saving time—they’re just ensuring that they’ll have to spend even more time troubleshooting and debugging as users come across problems.
On the other hand, some of us learn to code to make our own ideas come to life. For the solo inventor, entrepreneur, or builder, building out a full-featured product alone is daunting. It can be difficult to know where and how to begin actually writing code, especially without peers to work with. The decision to take a test-first approach can be the difference between a forgotten pipedream and a reality. Remember the “submit” button example from earlier?
Your Most Satisfying Code
Efficiency, readability, scalability—we can call these the functional benefits of TDD. If you just want to write better code more quickly than you could before, I hope I’ve laid out a good case for why TDD is a good place to start. I’m not the first person to make this particular argument, and I certainly won’t be the last.
But there’s one more reason you might want to consider adopting a test-first approach. To put it simply: test-driven development is just more enjoyable.
When I spoke to Alex Clark, I asked him why someone like me, a student without the programming chops of an engineer, would benefit from taking a testing-oriented approach.“I think a lot of times it’s cast as an advanced technique when in reality it makes programming simpler. It breaks down the problem for you and it’s very satisfying. You have small wins constantly.”
The “wins” he’s referring to are moments when the steps of a test that had previously failed begin passing. The very nature of TDD means that practicing it turns the programming experience into a constant stream of these wins.
“I think that’s the thing that’s most transformative about test-driven development. It’s a more satisfying way to develop. And then on top of that, you get a test suite at the end, and you get cleaner code, code that works.”
What to read (and listen to) next
If you’re interested in getting started with TDD yourself, Codecademy’s Test-Driven Development Pro Intensive lays the groundwork for a testing-oriented approach and was created with the thoughtbot team.
Alex Clark and Sean Doyle recently appeared on thoughtbot's "The Bike Shed" podcast to discuss TDD and the creation of the Intensive.
The team at thoughtbot played an instrumental role in creating the Intensive, and the writing on testing in their blog played an instrumental role in the thinking behind this article.
And one more time for the road, here’s some writing from the industry leaders quoted in this article on the benefits of test-driven development: