When TDD Isn't The Right Tool
I was recently talking to an enterprise software team about process, specifically test driven development, and was asked if I always do tdd and I realized that a lot of people who aren’t extreme programming or tdd practitioners think that us test driven weirdos always write tests first. I can’t speak for everyone, but as much as I love TDD and high test coverage: I write a ton of code without leveraging tdd. Sometimes I’ll write tests after, sometimes I don’t. Firstly, I’m a human (read: imperfect) and a programmer (read: inherently lazy). These 2 attributes can collude to convince me that I don’t need to worry about tests right now for this project. Sometimes this is a valid thought; most times it’s silly. I’ll explain why later. The big reason for deviating from TDD is that sometimes it’s just too dang hard. That’s actually something that many people don’t like to talk about in my experience, but tdd can be hard! Learning a new technology, a spike, or modifying legacy code are all areas where it can be difficult to write tests before your implementation.
For me, tdd wasn’t even possible until I learned a lot of other things about software craftsmanship. I still run into situations where, due to either poor requirements or poor understanding, tdd is just too painful. An example of this would be learning Vue.js to contribute to the Thinkster Real World project. I started out strong with tdd, and quickly got burned out. I decided to learn more about Vue on a separate git branch, and then go back to where I was on
master and get back to tdd. I’ll have to back-fill some tests as well, because I wrote a bit of code before deciding to take this new route.
Back to that part about not needing to worry about tests… I’ve burned myself a couple times with this mindset, so I really try to avoid it now (and suggest you do the same). Some of my longest-living code has been projects that I didn’t think were going to grow much, or be around long. Ever go back to code you wrote 2 years ago, and wondered “How the hell does THIS work?!”. If you’ve got tests, you’ve got documentation!
So if you’ve struggled to get started with TDD and you’re feeling discouraged, don’t feel bad. It’s hard. And if you’re like me or the majority of the folks I’ve worked with and mentored, TDD won’t really be possible until you learn about things like seperation of concerns, interfaces, loose coupling, and a lot of other things. If you’re a manager, please don’t expect your devs to ALWAYS do TDD; it’s just not feasible. Especially if it’s a new effort in your organization.