I’ve been thinking more and more about Test Driven Development in recent weeks. TDD is my preferred way to develop new applications, though I’m not as religious as some. I know that there are many that are still not convinced, and many more that are outright against the practice. (Read David Heinemeier Hansson’s post TDD is dead. Long live testing and Eric Gunnerson’s post #NoTDD)
I worked for many, many years as a software developer before discovering and practicing TDD. It was a dark time, full of bugs and difficult-to-maintain applications. Much of the fault was mine. Some of the blame could be shared by coworkers and those that committed the sins before me.
Rough draft, 2nd draft, final copy
Remember writing exercises in elementary school? Rough draft, 2nd draft, final copy. Writing code is no different. Uncle Bob has been known to say (I’m paraphrasing here) is that the best part about software is that it’s soft. Meaning, it’s easy to change. Or rather, it should be easy to change.
Without TDD applications are written quickly and without enough planning. How might a class be extended in the future? How might a new module be introduced. Too many developers write code that is buggy, fragile, and difficult to maintain. I’ve been there, I have the t-shirt. Deadlines are looming and we would be wasting time if we didn’t start coding right now!
While browsing twitter the other day I saw this tweet that I thoroughly enjoyed:
“I don’t do #TDD. Writing all your tests before writing any code is stupid.”
“I agree. If that was what TDD meant, I wouldn’t do it either.
— Michael Ibarra (@bm2yogi) July 2, 2017
Don’t misunderstand the purpose of TDD. Testability isn’t necessarily the main goal. Test Driven Development is about design. In traditional software development we may have a planning session, draw some UML on a white board, and go back to our desks to write some code. In the TDD world we might have a design session. We might even write some code in a spike to test out some theories. But in the end, it’s the tests that guide development, and the design emerges.
My favorite conversation I’ve ever been a part of was when a Directory of Engineering and former Sr Software Engineer at a notable streaming media corporation declared that the battle had been fought and the war had been won, TDD is just the way we develop software now.
Remember, development should be fun. We as developers chose to write code because it’s fun. We like creating applications and seeing them work, correctly. Have fun with it, grow your application through tests, and watch those tests pass.
And install or configure a fun test reporter like nyan cat!
Let me hear from you!
I want to hear about your experiences. Share your successes and horror stories.
What are your favorite tools and resources for TDD?
An author and Microsoft MVP, John has been a professional developer since 1999. He has focused primarily on web technologies and has experience with everything from PHP to C# to ReactJS to SignalR. Clean code and professionalism are particularly important to him, as well as mentoring and teaching others what he has learned along the way.