​025 As a developer, how to become proficient at TDD?

•start doing it

•If the problem is too hard: save for later after refactoring the code

You’re proficient when you:

•have written a dozen tests in an eight hour day

•have refactored a 4 big functions or classes to make them testable. 

•bristle at any suggestion of skipping writing tests

•A week has passed when you last used the debugger

You are a master when:

•you can teach others how to become proficient

•your team’s project has very good code coverage (> 80%) and still climbing. 

•Team’s technical debt goes down every Sprint

What must happen for a developer to become proficiency with TDD:

Write tests before product code. After a while your conditioned mind will learn a new habit. The 40 in 4 challenge is one way to do this. What this means is to write 40 unit tests over 4 weeks. Afterwards you’ll be a TDD breakthrough and be proficient. You will have encountered the half dozen difficulties your code presents to you and have discovered a number of remedies that allow you to do test first micro tests. You may have one or two challenges that you couldn’t solve but that’s ok. Keep going. Do it again for another 4 weeks and you’ll be an expert and will have equalized test first with product code first in your conditioned mind. You will enjoy and look forward to having the fast feedback that micro tests allow. You will also start noticing that your developing more features and spending much less time fixing buggy code.

What’s the most common reason developers don’t become proficient?

In episodes 14 through 22 of our IT drama, Agile Thoughts demonstrates several. Hands down, the most common reason is that devs are too comfortable with their conditioned mindset of “I can’t micro test code without writing it first.” And that mindset beats themselves into not even trying. And then, feeling uncomfortable, they accommodate their fixed mindset, skip writing the tests first and so they write the code first, even though that’s a slower way to get test and functionality and risky as frequently the tests are given short shrift. 

Next episode is about “Naughty and Nice” ways to compute team velocity, with Agile Coach Brandon Linton.