On Learning TDD Revisited

Test Driven Development (TDD) is a simple concept and deceptively difficult to get barely adequate at. I can teach people the concept of it in less than 30 seconds and it took me three years of working with to get “acceptable at”. Becoming “barely acceptable” at TDD will improve your coding skill, across the board, more than any other single coding technique that I know. TDD is writing one simple test first and letting it drive the implementation of that one simple step. There, I’ve now taught you about TDD. You can say that you “know TDD” and you’ll be part of the problem.

When I really introduce people to TDD I welcome them to a journey of exploration and deliberate practice. Because the only true way to get good at it is to practice it, experiment with it, and experience the joys of it. Along that journey you will make mistakes, experience hardship, doubt, and curse too. Like I said earlier though, if you stick with it, you will see a huge boost in your programming acumen. 

Some concepts that I cover when introducing TDD (all paraphrased, look up for more details):

• The Three Rules of TDD:    

  • You are not allowed to write any:        

    • 1. production code unless it is to make a failing unit test pass.       

    • 2. more of a unit test than is sufficient to fail.

    • 3. production code than is sufficient to pass one failing test.

• Four Rules of Simple Design:

  • 1. Tests pass

  • 2. Reveals intention

  • 3. No duplication

  • 4. Fewest Elements (simple)

• Red-Green-Refactor (RGR)

• Triangulation - in terms of TDD

• Pair Ping-Pong

• Deliberate Practice

• Code Katas (and that the problem is the lie)

• Learning Time (every day, earlier in the day/week as possible)

• Simplest First Step

• Testing behavior not implementation details

• Find a mentor

• Find a partner(s)

That’s not everything about TDD, but it’s a pretty good list to start with. Easily the best way to start working on gaining and improving your TDD skill is to do it with someone else, a group of folks is even better. Obviously a mentor that can help observe and give helpful guidance/thoughts/challenges can jumpstart things, but it isn’t required. I learned the basics solo and with partners with no mentor. It took me 3 years, but I did it. I’m stubborn like that. I also strongly suggest that you give yourself an hour a day to just practice a few things: 

1. Practice on the simplest first step for a new problem. 

2. Practicing doing TDD as close to “by the book” as possible, without skipping ANY steps.

3. Repetition

4. Honor the routine, but mix it up occasionally, disruption can offer insights and cancel out bad habits

The best way to keep growing your automaticity of TDD is deliberate practice and trying to practice it perfectly in small chunks. The best way to gain more TDD skills and break your own bad habits is to practice TDD with others (experienced practitioners of TDD and newbies!). I have bad habits and try to gain insight into them so I can break them these days. I’m also continually on the lookout for something to replace TDD, because there is always room for either improvement or better!

Some common gotchas (again certainly not all but some common ones):

• Trying to skip practice and just do it in production code. You can try this, but your learning will be stunted and bad habits will solidify. The pressure to deliver and the inability to experiment/fail safely will force you to cut corners resulting in bad habits and feel frustrated.

• Mocking frameworks are bad. In the beginning, please do use them but know that as you get more experienced and learn better coding techniques you won’t need or want them. I spent many years doing TDD constantly hearing “mocking frameworks bad” but didn’t know why until I learned other techniques. Just know they are bad and to be on the lookout on ways to not use them.

• Test behavior not implementation details. I’ve said it twice now and will say that this is an advanced TDD concept. Until you’ve experienced the pain of tightly coupled tests and refactoring nightmares of implementation tested TDD you’ll probably not get why I’m saying it. All you should care about is the result, not the details. 

• TDD is slowing me down! Whenever I start feeling this way I ask myself, how much time am I spending debugging my TDD code vs. how much time would I have been spending debugging/verifying code w/o my tests?

• TDD isn’t good for everything. While this can be true, it’s commonly thrown out there haphazardly. As you get more fluent with using TDD and build automaticity, it becomes less and less true. The most common of which is, “In a startup when speed to market is more important than high quality code”. This statement highlights the lack of understanding that working code is actually one of the lesser benefits of writing code with TDD. There was a time that I thought that and then there was a time where I delivered 13 fully working Azure prototypes (prototype isn’t the right term, they were fully functional vertical swipes that could actually go into production with some scaling tweaks) in 2.5 months until one got approved (remember that Jim Speaker?). The code is so simple it doesn’t need a test. To which I respond, “How many times have you found defects in ‘simple code’ and how many hours did you spend overlooking it because it was so simple it couldn’t be wrong?”

• Watching videos of TDD or even taking training...treat all TDD content (including this one) with a grain of salt. Size of that grain is TBD. There are a lot of expert-beginners that have TDD training content. There are lots of videos out there of people doing their take on TDD. I recently had a L7 Principal developer with 34 years of development experience tell me that there are at least 12 different definition of TDD out there. No there isn't. There are just lots of people who think that they what TDD is and here's their take on it and learn it this way (which, ironically, is essentially what this post is about too). There are a lot of good trainers out there (Kent Beck, Uncle Bob, James Grenning, Emily Bache, Sandro Mancuso, Sandi Metz, Llewellyn Falco, Fred George, Dave Farley...just to name a small few) and unfortunately there are a lot of bad ones. The best way to know who's good is to try them on and see how it goes. You can at least get different insights into what aspects people find important about TDD and create your own.

• Writing ALL the tests ahead of time. This is not TDD. You should go back and check on your fundamental understanding of TDD.