Code coverage is the metric everyone knows - but is it really what you need to be using? 

In an upcoming talk this Wednesday, February 17th at 11am ET/4pm GMT, Enrico Trentin, the developer relations lead at Diffblue, will answer this question, walk you through the code metrics that actually matter, and explain how to identify areas of risk and efficiently improve them with manual and automated means, using examples from FINOS open source projects and data-modelling platforms.

Below is a primer for what we'll be discussing during Enrico's talk.

Register below to receive a link to the webinar

Background for the talk

Below, we have defined some of the technical terms that you might hear, to accompany the talk "The Code Coverage Paradox: When 90% Isn’t Enough, But Less Might Be," and help contextualize the conversation. 

By: Madeline Bien, Content & Communications Manager, Diffblue

Talk abstract

Code coverage is the metric everyone knows (but if you don't, keep reading below) - but is it really what you need to be using? In this talk, we will walk you through the code metrics that actually matter, identify areas of risk, and efficiently improve them with manual and automated means, using examples from FINOS open source projects and data-modelling platforms.

What is code coverage? 

Code coverage is a metric that tells you what percentage of the "units" of code in your application have unit tests written for them. Many organizations use code coverage targets to determine whether they have sufficient tests to protect their code; higher coverage is generally seen as better.

What is a regression?

A regression is any change in code's behavior. Regressions can be intended or unintended; when they are unintended and the developer is not aware that they have occurred, they can cause expensive and hard-to-fix issues. Unit tests can alert developers to regressions, because if the behavior of the unit under test has changed, that test will fail.

What are trivial methods?

Trivial methods are common methods which are short (often just one line) that contain little-to-no logic ('getters' and 'setters' are common types of trivial methods). They often make up the majority of the codebase. Testing these methods does not actually provide much protection against risk, because they do not cause behavior significant enough to post a threat to the function of the application if their behavior changes. 

What is legacy code? 

Legacy code is code that was usually written a year or more (or decades) in the past and is not well documented or tested; because few/no people in the organization have any firsthand experience of working with it, it is risky to have a lot of it; if it breaks and needs to be repaired or rewritten, it's difficult to repair. It's also hard to write unit tests for code that nobody can understand, which is why having extensive legacy code can make it hard to increase code coverage in an application. 

What is testable code?

Testable code is written in such a way that all of its attributes are accessible with unit tests, so all of its behavior can be verified and any unintended changes or bugs can be caught early. Untestable code can be refactored (rewritten without changing its behavior) to make it more testable.

REGISTER HERE

When: Wednesday, February 17th at 11am ET (4pm GMT)

Talk: The Code Coverage Paradox: When 90% Isn’t Enough, But Less Might Be

Talk Abstract: Code coverage is the metric everyone knows - but is it really what you need to be using? In this talk, we will walk you through the code metrics that actually matter, identify areas of risk, and efficiently improve them with manual and automated means, using examples from FINOS open source projects and data-modelling platforms.

Speaker: Enrico Trentin, Developer Relations Lead, Diffblue

Interested in this FINOS open source project, or any of our other projects? Click the link below to see how to get involved in the FINOS Community.