Archive for June 27th, 2008

• “Unit testing never took off”

  Date: 2008.06.27 | Category: Practices, Testing | Response: 0

  … said Agitar CEO Jerry Rudisin from SD Times.

  “The practice works, but it hasn’t taken off as a mainstream practice.”
  

  In 2008, I find this quote surprising and saddening that we still do not have software developers recognizing the need for automated unit testing. Sure, a lot of people now talk a good game about unit testing (how can they not since it is talked about so much), but they don’t really buy it. I see it with the teams I work with today and teams I worked with in the past. When I was interviewing at SAIC, I specifically asked the team if they did unit testing (it was my minimal qualification for the job) and I got nods from everyone at the table. Little did I know that we were talking about completely different things: I was talking about Michael Feathers’s definition of unit testing and they were talking about a more classic definition of unit testing. It was an immediate mismatch of expectations and goes back to an earlier post on being precise in language.

  So how do we bridge the gap and help people understand the value of automated unit testing? I think the first step is to help people understand that testing is really a design activity. Writing automated unit tests is defining your API so that it may be consumed by its very first client, the test harness. I have always believed (and found through practice), that if your application is hard to test, the design is likely overly complex. Tests that are hard to set-up, or exercise, normally mean the classes are too tightly coupled. Or put another way, the classes know too much about the internal workings of other classes and your design concepts are not properly encapsulated, i.e. you have leaky abstractions.

  I understand it is hard to change the way we code, especially if we have habits that have helped us be successful for many years. However, what really has helped me crystallize the importance of writing automated unit tests and practicing TDD is a quote I heard from Alan Shalloway, and I am paraphrasing here:

  “I am putting the bugs into the system. There are no people, or gremlins, coming in at night sprinkling bugs while I am gone. It is me, so I need to do practices that stop me from putting more bugs into the system and TDD is what works for me.” [emphasis added]

  So, I guess the first thing that needs to happen is not learning testing is a design activity, but accepting responsibility we are responsible for the low quality and wanting to make things better. Without that, unit testing will never take off.