Test Infecting a Development Team

Most developers and managers alike know there is great value in unit testing. To this day, I have never met a manager who does not want developers to do unit testing of some sort. Developers know that they should be writing tests for their code, but have various concerns as to why they don't. This article summarizes the top reasons developers don't write unit tests. It also recommends a strategy of “test infecting” an entire development team.

Software testing is not a new trend. Developers have been testing their code in one way or another since the inception of computers. For example, developers write the code, install it, start the application and begin testing the section of code they are working on. In many cases, they will even write hooks into the application to allow it to be manually tested more easily. They run the application in debug mode, making sure that certain lines of code are executed with the correct variable state. No matter how it is accomplished, developers inherently feel the urge to test their code. The goal of this document is to identify how to create a climate that will sway that urge to a more efficient and valuable means of testing code.

Key Reasons Developers Do Not Write Unit Tests:

1. There are no obvious benefits from writing unit tests. Most developers will not make the investment until they have seen the proven returns. However, unless they try writing unit tests, they will never see the benefits that arise from good unit testing.
2. Unit testing is intimidating. Learning how to unit test is similar to learning a new culture. Developers do not know where to begin; let alone how a given section of code can be unit tested. Often times, developers have been introduced to unit testing before, but have reservations about writing unit tests against a complex scenario. The mentality can become that there is no sense in learning a technique for something that is only useful for a small number of cases.
3. It takes too much time to write unit tests. It is often believed that unit testing slows down the development of the product too much. Somehow, the feeling is that constant manual testing, usually requiring deep navigation into the application, is acceptable, but writing code that tests a method in the code isn't. In a recent study at Google, it was found that seventy percent of the developers who refuse to write unit tests do so because it is simply too much work. They claimed that on average every line of code required around four lines of unit testing code.
4. Many developers do not know what is expected of a unit test. They do not know what to unit test, what not to unit test and what an acceptable unit test is. When learning a new technology reluctance is expected. This reluctance is usually resolved by giving the developer time to learn. However, this same expectation is not usually given to developers with regards to unit testing. Instead, it is simply an expectation assumed by other team members or mandated by management, making the pressure of not failing all the greater. Even a seasoned developer with good unit testing habits regularly finds new innovative ways of unit testing.

Developers need to feel that unit testing is not something they are doing to accommodate a requirement, but is a tool that can become one of the most useful tools in their toolboxes. Unit testing should make the developer feel empowered, not restricted. For the majority of cases, unit testing is a more useful tool than the debugger is. The more unit tests there are, the less the debugger is used.

The goal is not to just have developers write unit tests. Developers need to write good unit tests. We need master unit testers that write unit tests just like they write code. They need to have the same passion about unit testing that they have about coding. They must become test infected. The word infect means “to affect in a contagious way”. Test infected developers have passion about unit testing, sharing the many benefits of unit testing with those around them. Test infected developers see unit tests as a necessary tool when writing code. Developing without writing unit tests becomes unimaginable. Test infected developers plan out a unit testing strategy just like they would a development strategy. They find patterns in unit tests and create efficient techniques that lessen the work required to unit test, such as helper libraries specific to the application being unit tested.

Test infecting a development team has proven to be among the most difficult goals to achieve in this industry. Most organizations simply mandate unit tests. Simply requiring a particular practice has not proven successful in the past. For example, the industry has been insisting on documentation for years and to this day good documentation is something rarely seen. Documentation can be seen as a feature of a product, but it still often times gets skipped. Unit tests, on the other hand, are never seen by the customer, making it even harder to enforce. Developers must see the benefits before they will commit to writing unit tests. This requires a commitment to resolve their concerns and giving them the time and resources required to learning good unit testing practices. Test infecting a development team requires complete support from management.

Over the years, it has been shown that test infecting a development team requires commitment and a reproducible process. With this in mind, a good strategy is to pick a member of the team who is a good people person, shows interest in unit testing and realizes the benefits. One way to accomplish this is by programming with each team member, introducing unit testing to each one and resolving concerns. The earliest adopter who is hopefully a good mentor is always the best candidate. Once chosen, time is invested in showing the return of investment as well as the ins and outs of unit testing to the developer. Programming with the developer is crucial at this point. Doing so will answer any questions immediately and it will help demonstrate alternative ways to writing the tests. This helps infect the developer, giving confidence and answers to many questions asked by those learning how to unit test effectively. The developer will soon become test infected.

Once the contagion is planted, it will spread across the team. The process simply begins again. Only this time, the test infected developer will become the subject matter expert on the team. He will program with each team member and help choose the next developer to be infected. He will want to make unit testing easier for his teammates. He will be responsible for resolving any concerns regarding unit testing on his team. The excitement and passion about unit testing will spread to other members of the team with time, leaving only a few who simply refuse to unit test. With the organization's mandate to unit test, the last few resisting will not only be required to unit test, but they will have been trained on how to do so. Those last few will have the complete support of their team and management to help them succeed.

There are several concerns that developers have about unit testing. If these concerns are ignored and unit testing is simply mandated, then getting developers to unit test is not very likely. However, if some time is invested and support is shown by not only resolving their concerns, but also showing them all of the benefits of unit testing, the possibility of developers realizing unit testing is simply another tool to put in their toolbox greatly increases. If developers acquire the desire to unit test, then the quality of the code, the unit tests, the application being released and the developers' skills will drastically improve. The management challenge is to find the early adopter with the courage and vision to take that first step.

If you are running into the chicken before the egg problem, then training is a great option. There are also local user groups that the developer can attend. Of course training and attending user group sessions will greatly help, but it may take some time. The important thing is to be patient, empathetic and supportive. Having a small pilot project for the developer to do in his spare time is a great way for the developer to practice what was learned from the conferences and user groups. It would also likely speed up the learning process. Another option is to bring a consultant for a month or two for that developer to work with. In other words, be resourceful! In the end, put this person into a situation where he can be successful on the first effort. Don't forget this person is still new to it and might become discouraged unless you are there to constantly support him. The good news is, he is likely wanting to spread the joy.