Our overarching goal in agile and DevOps is to deliver increments of customer value more quickly with acceptable quality. In doing so, we employ many approaches and techniques to verify requirements, designs, and code at every step in our software engineering methodology.
One key practice in driving early defect identification is unit testing, but several organizations and teams continue to be challenged when it comes to designing and implementing unit tests.
A question I continue to be asked is how to engage developers in this respect. The difficulties usually include poor build quality, later-stage defect identification, and increased rework, which all slow the delivery of value increments to users.
Traditionally we’ve approached testing, manual or automated, from the UI perspective, so teams usually have more UI tests than unit tests as they begin their agile journey. Driving testing to lower levels of the application or system under test results in earlier defect detection at the structural levels of the code and easier defect identification and repair due to decreased complexity.
Of course, comprehensive unit testing does not eliminate the need to test at higher levels, but it contributes significantly to reducing rework delays and improves predictability in our sprints and releases—whether tests are written first, as in a test-driven development approach, or unit test are written after the code. Unit testing adds significant value.
Here are some suggestions for how to instill a unit testing culture.
First and foremost, leadership must value testing. They should nurture and support a culture of testing early and often for continuous feedback. That means there must be a balance of speedy change or feature delivery to code quality, and developers must be given the time to design and implement sound unit tests.
The goals and incentives for individuals and the team also must be aligned. If developers are goaled on “more code faster,” the first thing to go will be good unit testing. Recognize and reward developers and the team on great unit testing practices.
And answer the WIIFM question: What’s in it for me? Communicate the benefits of unit testing and highlight the consequences of poor unit tests through quantitative metrics and root cause analysis.
Also provide training for developers in efficient and effective unit testing techniques and approaches, and ensure developers have the tools they need to design and implement solid unit tests. Few of us were formally trained on testing during our university years.
Set guidelines, requirements, standards, or norms so that the accountability and expectation of conducting unit testing is clear. For example, specify change and feature submission criteria that includes unit testing prior to and during the build.
Finally, conduct code reviews, practice paired programming and unit testing, conduct static and dynamic code analysis, and track the key metrics from these methods and tools to determine the effectiveness of unit testing. When downstream defects are discovered, understand the root cause and investigate whether additional unit testing may mitigate these downstream risks.
I’ve not yet met a developer who purposely inserts defects in code. In my experience, realizing a culture of sound unit testing is more a leadership challenge than a developer one.
