A few years ago, I scheduled a meeting with the software engineers on my team to introduce them to Test-Driven Development (TDD).

I had started reading the book “How Google Tests Software” and I felt I had to share what I was learning. I started a book study with the team.

The first thing I wanted to focus on was unit tests. This was a completely new concept to the team and to me. I looked around online and found some good tutorials and a video from a teenage developer who was showing other engineers how to write their first unit test.

I built a Google slide presentation and walked through it with the team.

One of the first slides focused on the reasons (excuses) why engineers don’t write unit tests:

• It’s too late to start
• It’s too much work
• It has to be maintained
• It slows down real development

For each of these reasons, I added a translation into what it really meant:

• I don’t know where to start.
• This looks scary. Am I a tester or a developer?
• I don’t want to maintain this code, too!
• I have deadlines for real features!

My goal was to head-off the concerns early. I put myself in their shoes, thinking about what it would mean to add unit tests to my code. One thing that really hit home with me was “I don’t know where to start.”

I encouraged the team to start writing unit tests. I showed them the video of the teenager writing them. I called him “Kid Coder” and I told the team — “If Kid Coder can do it, you can, too!”

It worked, the team started writing unit tests. Most never got to the point of actual test-driven development where the tests are written first followed by the code. But we now have thousands of unit tests to go with our many projects.

The second half of my presentation — which we covered on another day — focused on the role of software engineer in test (SET). I wanted to train them on this concept because one of our next steps was to hire an SET and to set up a build server which could also run our unit tests.

It wasn’t long before we hired our first SET and set up a Jenkins server. Not only do we now automate unit tests, we’ve also automated our builds, our code style checks and more. We spawn test nodes in the cloud when we are testing certain projects and more.

It’s come a long way since that first presentation.

Now, I don’t write code too often. My team discourages it! 🙂 And I have other things to do. But I have a few side projects — some for business and some for personal use. I have a lot of code to support web projects. I write in Perl — and I’ve gotten pretty good at it

Can you guess the one thing that I had never done? You got it — I had never written a single unit test.

What a hypocrite. What had been blocking me? I didn’t know where to start.

This weekend, though, that changed. I did some research on Saturday and before I knew it I had five unit tests. Then I had eight. It’s Sunday and I’m up to 71 unit tests.

Writing the unit tests wasn’t all that hard. The hard part was fixing all the bugs I found!

Yup, I found multiple math errors, poor error-handling, incorrect date formatting and some bad regex that just didn’t work.

It’s amazing. I’m converted and I can’t imagine writing code in the future without writing my unit tests.