A 5-Step Process to Move Towards a Unit Testing Culture in Development Teams

Ideas to Overcome Inertia to Change

Photo by Bill Oxford on Unsplash

1. Find others with the same objectives

The biggest objection to increasing unit test coverage is that it takes software engineers away from developing new features for clients. Additionally, the transition towards a unit testing culture will take time and require an investment in training.

A lack of team support would almost certainly hinder any effort to move towards a unit testing culture, so it's essential to recruit like-minded people first.

An excellent place to start would be to persuade a manager or lead developer who can convince everybody else in their team to do the same. Find out if they share the same goals and how you might go about convincing management.

2. Prepare for obstacles

Photo by Randy Laybourne on Unsplash

It’s essential to make a list of people who are likely to oppose your reforms and brace for tough questions, like:

• How much time will developers be required to devote to unit testing?
• Adding unit and end-to-end tests would almost certainly double the time it takes to launch the next version. If we’re already behind on releases, what justification would you give our clients for pushing the dates further?
• If we give you this much money right now, what part of the website would you prioritize adding test coverage, and why?
• Is there another team that has already done this?
• What are your metrics to prove that the additional effort in unit testing has reduced the number of production bugs or bugs discovered by QA and returned to the development team?

3. Choose the best path to start

Photo by Caleb Jones on Unsplash

Implementing unit tests in a codebase — particularly one with lots of legacy code — can seem incredibly overwhelming at first.

Ask yourself:

• Who in the team is willing to learn and experiment with unit testing practices as a sub-group of the wider group?
• Is there a low-risk, low-priority feature that we could use as part of the trial to obtain some benchmarking figures?
• Once we’ve become familiar with unit testing best practices, which codebases would benefit from better coverage?
• What parts of your website generate the most production tickets and pose a reputational risk?
• Where are regression bugs being frequently found after each new release?
• Using benchmark figures, approximately how long will it take to add these tests?

4. Make progress noticeable

Photo by Jerry Zhang on Unsplash

Here are some suggestions to make your testing efforts visible:

• Keep a TV screen up that displays the latest test coverage percentages.
• Send a morning email/team channel update summarising the latest code coverage statistics.
• Create metrics, measure where you are now from where you aspire to be, and gather benchmarking data to find out how to close the difference (you’ll need solid data to back up your funding requests).
• Run training and awareness webinars and workshops.

5. Get outside help

Photo by Tim Mossholder on Unsplash

Change isn’t easy, and it’s sometimes tricky for internal employees to look over existing practices with a critical eye. Perhaps the answer could be to hire a contractor from outside? The reasons for this might be:

• A consultant won’t have a bias for any particular team or division.
• He/she will find problems and make recommendations that employees may feel uncomfortable bringing up.
• A specialist would be more familiar with dealing with internal opposition.
• They would most likely have clear solutions to complex problems after doing the same in numerous other organizations.

Thanks for reading! Let me know what you think in the comments section below, and don’t forget to subscribe. 👍