Test-driven development, or TDD, provides software engineers with valuable insight during the development process. For some developers, it’s key to creating higher quality software in a fraction of the time.
However, for those new to TDD, it can be difficult to understand, and it can leave you with a lot of questions. In order to help you use TDD to generate real results, we sat down with experienced software engineers to help answer your most pressing TDD questions.
Follow their tips to gain a better understanding of the value of TDD, learn when you should use it (and when you shouldn't), and discover how to leverage TDD to aid your design and help you and your team create better, faster software.
Stop running bad retros. Discover the secrets to facilitating retrospectives that drive real results.
What value does test-driven development (TDD) give us?
“For me, it’s a sense of direction, a sense of accomplishment, and just feeling more confident as we go along in the project. Feedback being one of the core principles of programming, that’s what TDD gives me. That feedback, the confidence, the desire to explore more, and then to know when I’m done.”
一Ariel Valentin, Principal Software Engineer, Gust
“I think the big thing it gives me is constant feedback of when I’m making progress. Like if I just take the “sit down and try to code something” approach, I have a hard time actually noticing that I can get stuck…like, I’ll get stuck on something, but that doesn’t manifest as “getting stuck,” it manifests as “first I need to figure out [x, y, z]”. And then three hours later I look up and realize that I have no idea what I’m doing. Whereas with TDD I get into this nice little rhythm of tests, so if I miss a few beats I can ask myself, “When’s the last time I made a test pass?”
一Moss Collum, Senior Software Engineer, Luminoso Tech
“It’s about being able to fail fast and knowing that you’re on track with the functionality that you’re building. I find that without tests, it's hard to really gain a direction and gain focus on what’s being built. I find TDD enables short feedback loops, being able to understand that starting off with something simple enables you to come up with a complex solution over time. Knowing something that you build and hour ago still works.
“So I think TDD aids design and is a part of that, also helps that knowing you’re not regressing way into the future. For me, the design of a software system becomes very different when you test drive its development versus when you just cobble things together without any tests. I find that the classes I create tend to be smaller, and more focused on doing one thing at a time and doing it really well. And by having tests, my future self can be confident that my former self got the test right.”
一Conrad Benham, Principal Consultant, Stride
Are agile engineering practices [such as TDD] always best practice?
“TDD and Refactoring are almost always best practices. But not 100% of the time. I’ll paraphrase Kent Beck from a recent Startup Success podcast: ‘something that might be good engineering practice when taken in isolation might not be good startup practice.’ Spending time on sustainability practices is effectively slowing down your Learn-Measure-Build cycle.
“As a rule of thumb, if TDD helps you learn faster, then do it. For example, a calculation engine I built last week for an MVP has a fair amount of tests around it, because trying to build that without tests would actually be slower the first time around. Therefore, testing actually helped me get through the Learn-Measure-Build cycle faster.”
一Rex Madden, CTO, Stride
When would a developer choose not to do TDD, and when would that be the right decision?
“Being a front-end developer, it’s hard to test drive the design process. On normal code, when you’re writing the unit test, you can write the test as soon as you’ve decided on a name, the inputs, and the output. On the front end, I don’t know if I need an anchor, a link, maybe I’m redirecting to a new page, or I’m staying on the same page and modifying something. So I need to try these out and think about what the user wants before I can write a test for it. It’s hard to test the user experience as the correct way to go about it.”
一David Newell, Front-End Software Developer, Tapad
“I think it comes down to things that slow feedback down. So, if it’s faster for you to do something and it’s always faster than it is for you to automate it if you do it manually, just do it manually.”
一Ariel Valentin, Principal Software Engineer, Gust
What do you recommend engineers do to ensure TDD leads to good design?
“When I was first learning TDD, it took a long time for me to get to the point where I felt like TDD was helping with my design. I think in the beginning, for someone who’s new to TDD, don’t feel like if it’s not helping with the way you design things right away, don’t get caught up in that. Just do the TDD cycle and get used to that feedback loop, and eventually the design aspect comes a little bit later. So that would be one piece of advice I would give to someone first starting out: don’t think it’s going to miraculously think it’s going to help with better design right away.”
一Bob Nader, Principal Software Engineer, Gust
“TDD is an excellent tool for improving design, as long as it’s used as a tool and not a panacea. TDD can help you see new ways to improve your design, but some of those aren’t obvious. You are a programmer and have to pay attention and be creative. It won’t just happen automatically. If TDD is pushing your code in a direction that makes the design worse, stop and think about what you can do differently. So pay attention. Think about design. And if TDD is pushing you in a direction that makes your code worse, stop. Take a walk. Talk to a colleague. And look for a better way.”
一James Shore, Principal, Titanium I.T. LLC
- Developers should leverage TDD’s short feedback loops to ensure the project is on track.
- If you feel TDD is slowing your process down, it’s probably best to do without it.
- It takes a while to get the hang of TDD, so don’t get discouraged if you don’t see an immediate improvement.
Want to learn more strategies to help your team build better, faster software? For agile teams, proper use of retrospectives are key to a consistently improving team. Our free guide covers everything you need to know to facilitate your retrospectives like a pro.