Steve Berczuk: How does TDD change the way that you think about your code and your design?
Dan Wellman: I've found that practicing TDD means that I have to think about the design a lot, and that can be hard! When I first started practicing TDD, I wrote tests before my production code, but I didn't notice the design smells in the production or the test code. That led to a test suite that was overspecified. Changes to the production code would cause tests to fail even when there wasn’t actually a mistake! That makes development slower, not faster.
As I've practiced TDD more, I've learned to slow down a bit and think about the design of my code—in the small at the object level, and in the large at the system scale.
Steve Berczuk: What are the major cultural challenges to adopting TDD?
Dan Wellman: Generally, if some developers on a team practice TDD and others don’t, then the team may not get all the benefits of TDD. I’ve seen the benefits pay out when everyone on a team is following the same practices, encouraging each other, and learning.
If the project sponsors won't allow slack in the schedule or scope for the team to learn how to practice TDD, then that's a recipe for a problem. Velocity usually drops while the development team learns to apply TDD, though hopefully quality (and predictability) is improving. If the team starts experiencing time pressure, then there needs to be safety and space to keep practicing TDD, or it tends to be one of the first things jettisoned.
Steve Berczuk: How to you encourage skeptics to try TDD?
Dan Wellman: Well, if they absolutely aren't willing to try it, I won't try to coerce them into doing it. Instead, I'll try to find folks who are interested in trying it and work with them.
If they are willing to talk with me about why they are skeptical, I'll ask them what challenges they’re having with their development process. If I suspect TDD might help them with their challenges, I'll tell them, and I'll be honest that it might or might not help them and it might be hard. If they're interested, I'll ask them to try it with me for a little while. I'll choose something to work on that I think could address some of the problems they’ve mentioned.
Steve Berczuk: How does using or not using TDD affect other aspects of the software development cycle?
Dan Wellman: I work on teams that prefer to follow the XP practices, which means following what James Shore and Shane Warden call "simultaneous phases." That means that many phases of the software development lifecycle—requirements, design, coding, and testing—are happening at once. TDD is one of many practices that make that process possible.
I've worked at other jobs that didn't use an agile process, but I practiced TDD on some of the code I wrote for those projects. When I did use TDD, I felt more confident in the code I delivered, and I was less worried about making a mistake that caused an emergency.
Steve Berczuk: Thanks for helping us understand the various aspects of TDD. I enjoyed our conversation. It seems like there is definitely more to TDD than simply writing tests. Any last words for someone who wants to get started with TDD?
Dan Wellman: Thank you, I enjoyed it, too! The good news is that there are now many ways to learn about TDD. There are plenty of great articles, books, screencasts, and example projects available. I'd encourage someone new to practice, be persistent, and take pride in each new accomplishment or lesson learned.