I have published a number of blog posts about TDD. I have written about the pros and cons. I have written step-by-step walkthroughs to solve problems. In writing these posts, I realized that there is an important part of using TDD that is easy to overlook. It feels natural to people who practiced it for a while. Experience makes a big difference in how effective TDD is. It is easy to dismiss TDD as ineffective because there are so many ways to use it incorrectly. For this blog post, I will describe my experiences to encourage others to find how to make it work for them.

In my walkthroughs, there are times when I make seemingly arbitrary design decisions. I give little or no explanation as to why or how I arrived at that decision. In general, I make these decisions based on experience. If I see a pattern emerging, while I’m looking at some code, I take a step back and think about how to implement this pattern. There are a million ways to do something in programming. How do I decide which one? I choose the path that looks the most clear to me, meaning that I can clearly see the solution before I start writing it. This only comes with knowledge and experience in programming, so there’s no trick or shortcut to it. Let me give an example from one of my previous blogs, a TDD Walkthrough of the Encryption problem.

I reached a point where I needed my encryption function to return a string of words separated by spaces. Up until that point, I had been using for loops and strings to implement my solution. The spaces that separated the words became an issue because I didn’t have an simple way to do it under the current for loop and string manipulation structure. Then I recalled that javascript arrays have a join method that joins its string elements into a single string, adding an optional separator of your choice. Using an array join would be less code and more clean, but it required restructuring my code, converting some strings to arrays and some string concatenations to array pushes. With a little bit of restructuring, I was very satisfied with the end result.

I ended up with a clean solution to the Encryption problem thanks to some knowledge of the language, and some experience in solving similar problems. One can only gain this experience by seeing someone else do it somewhere, and then trying it for yourself. So, my advice to understanding and then doing Test Driven Development well is to seek out good sources and references, and try them out yourself. It is very important to go through the motions and steps. We humans surprise ourselves all the time with what we learn by actually doing. I am a fan of J. B. Rainsberger and his course, “The World’s Best Intro to TDD“. I would also suggest going through my TDD Walkthrough blog posts if you haven’t already. Should you find other sources and references, I ask that you share them among your peers so that we may all learn more.

Share This