The Communication Aspects of Code Testing

Code Testing in all its variations is considered to be a no-brainer for state-of-the art software, and rightfully so.

While there are many different techniques and approaches to code testing, there is an aspect which in my opinion is underappreciated nowadays: code tests can tell us much more about the code and the environment it is produced, and can be used as a very important communication source for software projects.

Communicating Code Health through Metrics

Code test coverage is a metric which can give hints about the health of a software system. While the absolute value is not that interesting, some aspects of historical code coverage might tell more about the project in which this code is produced: does the coverage go up over time? Do new team members have an impact on it?

Do not read to much into dashboard informations, and be always aware that such metrics can easily be manipulated.

Requirements Documentation

Tools like Cucumber transfer requirements to code by supplying a glue in the form of a domain specific language (DSL). This glue is expressed in a almost natural language and is implemented in program code. The vision here is that business people and programmers create a working piece of software out of a description of what the system should do and how it does it. This may be a pipe dream in many projects, but even if the scenarios are written solely by one party, there is a visible flow from business to implementation level.

Implementation Documentation

While the static parts of a software system are well communicated via code documentation or tools (e.g. Swagger), code tests can describe the dynamic aspects of the system. New programmers may gain most knowledge about a software system by studying its test suites.

I think that this is one of the most underappreciated aspects of tested software. Well written test cases can be seen as an onboarding help for new developers.

Confidence in the code, Self-Confidence for the programmer

Having a well tested software serves as confidence boost into the software. Testable software tends to be better designed, be less brittle and allows a team to try out new things or optimise the existing system by e.g. refactorings and changes.

This confidence communicates throughout the team and generates positive enforcement loops. This can spread to all stakeholders of the software system in best case scenarios, and allows for bolder moves and testing ballons.

Happy Testing Unicorns Everywhere?

So is code testing the answer to all problems in software development? Of course not. Testing is an engineering domain in itself, and may overwhelm both programmers and stakeholders. Therefore it is important to manage tests as integral part of the software development process, by e.g. reviewing the necessity and utility, and also in the end the business value of those tests in an agile process.

So what is the point?

There is more business value in code testing than "only" the code under test. It is our job as software engineers to communicate those added values to the stakeholders.