Seeing unit testing catch on and flourish with a new team has made the last few months at work pretty fun for me. Getting to this point, though, has been a ton of work. Considering the journey toward unit testing can have a lot of twist, turns, surprises and disappointments, I figured it would be a good time to recap in hopes my experience helps others grow unit testing within their teams.
Set an Example
A lesson I learned early from unit testing my own code is that evangelizing a new idea is never as effective as demonstrating a new idea. I can tell people about benefits all I want, but it’s not until I show benefits that people start to pay genuine attention. If you think unit testing is right for your team but you’re undecided about where to begin, start by setting an example. You can do it entirely by yourself. You don’t need budget or buy-in. Just take a design module or testbench component, build a unit test suite around it, take note of what bugs you find, the improvements you make and the lessons you learn.
Our hardware verification paradigm generally consists of subsystem and chip level testing; both of which can be incredibly complex. It can take hours or days to describe testbench details to colleagues. One advantage of unit testing is that it gives you the opportunity to truly start small while still providing value. Setting an example with a small RTL design module or verification component, you can build a unit test suite that takes anywhere from a few minutes to a couple hours to describe which makes unit testing feel far more manageable that what we’re used to. So to start, keep the scope narrow and the complexity low. Think of the example you set is a baby step; the first of many, many baby steps.
Make Your Example Visible
For people to follow your example, they need to be aware of it; for them to be aware of it, it needs to be visible. Create awareness around your example so people have the chance to see what you’ve done (you may be surprised to see people find you completely by accident!). You could post an article on the company intranet or put together a presentation. Offer to present what you have to your team. If no one takes you up on the offer, wait a while and offer again. Or offer it to another team. If you go out of your way to be visible, sooner or later someone will want to know more.
Assuming your example shows how easy it is to get started with unit testing (hint, hint), once people finally do take notice it won’t take them long to try it themselves. Of course packaging your example will make it easier for them to try it, but undoubtedly they’ll have questions and they’ll need help from you to really get going. So be prepared to help teammates get through their first few unit tests. They will appreciate it. You’ll also be there to ensure they approach their own unit testing as the simple, low level testing it’s intended for.
I consider my first credible demonstration of unit testing (or test-driven development as it were) to have happened back in 2012. I was public with the experience and the results – which for me were fantastic. I blogged about it and worked my experience into conference talks, basically doing everything I could to show people how my quality and productivity had improved as a result of unit tests. With all the effort, it wasn’t until last year that I was able to turn that first success into something larger within a client development team.
That’s three long years.
Admittedly, there were many times in those three years where I felt pathetically ineffective. Yet, having just completed a client engagement where I’ve helped create a small team of advocates that are genuinely excited about unit testing, I finally feel like all the effort was worth it. Well short of a cure for cancer or a solution to world hunger, but it’s a step forward, and it feels good.
The bottom line for people striving to introduce unit testing to their design or verification teams: be prepared for an adventure! Hopefully you can use my experience for guidance. By setting an example, starting small, being visible, available and most of all patient, I like to think you’ll get to success much faster than I did!