Balancing Automation and Human Review

This lesson reviews another area surprisingly resistant to automation: checking code quality.

Static code analysis tools for code quality

As we’ve seen throughout this course, TDD is primarily concerned with the design of our code. As we build up a unit test, we define how our code will be used by its consumers. The implementation of that design is of no concern to our test, but it does concern us as software engineers. We want that implementation to perform well and to be easy for the next reader to understand. Code is read many more times than it is written over its life cycle.

Some automated tools exist to help with checking code quality. These are known as static code analysis tools. The name comes from the fact that they do not run code; instead, they perform an automated review of the source code. One popular tool for Java is Sonarqube, which runs a set of rules across a code base.

These rules can be modified and added to, allowing customization to be made to the local project house style and rules.

Automated limitations in code analysis

Of course, such automated assessments have limitations. As with manual exploratory testing, there are simply some things only a human can do (at least at the time of writing). In terms of code analysis, this mainly involves bringing context to the decisions. One simple example here is preferring longer, more descriptive variable names to a primitive such as int, compared to a more detailed type such as WordRepository. Static tools lack that understanding of the different contexts.

Automated analysis vs. human review

Automated code analysis has its benefits and limitations, as summarized here: