Code Coverage

Greetings, friends, colleagues and... penguins! Code Coverage - 1

Today we will talk about Code Coverage , we will figure out what it is, why it is needed and how to upgrade your open-source project by providing Code Coverage statistics. This article is a laconic continuation of the previous one about Continuous Integration . Here we will learn another powerful advantage of CI in combination with... and soon you will find out with what! I will only emphasize that there will be no instructions here on how to correctly write tests for your programs, and how to achieve the maximum possible useful coverage; this whole sin will remain only on your shoulders. So, let's go!

What is Code Coverage?

Code Coverage is a certain value that shows us the percentage of source code completed during testing. Okay, everything seems clear here. The Code Coverage percentage can range from 0 to 100, and the question may arise: should you strive for the maximum CC percentage? My answer is: yes and no. Why is that? Let's say you create a project that will be used by some other projects, it is full of functionality, and among all the horror there are getters and setters, and there are quite a few of them. When covering the functionality, not all, say, getters were covered, but you know for sure that those that were not covered are not called in your project, but getters are not always written “for themselves,” so they are needed for the “client”. What to do? Cover each getter separately? This will not be effective testing. But if we don't cover them, we won't achieve the maximum CC percentage. This is where a double-edged sword arises.

Why do we need Code Coverage?

I think the answer to this question will be very simple: Any code needs testing so that when refactoring or adding/changing functionality, “invisible” bugs do not arise, and we can track them. We won’t run through frameworks with breakpoints and debuggers and catch this vile Bug. Life is too short. Example So, the most interesting thing. The task is this: Introduce into our open-source project , which we wrote in the previous article , a technology that will collect information about CC, process it somewhere, and it will be possible to place this information on GitHub in the form of a badge, for example. All source code will be posted on my GitHub .

Let's start by choosing a plugin to collect code coverage information into one pile. I personally chose JaCoCo , which collects information about code coverage. But there are also alternatives .

The JaCoCo website offers us to download the plugin, but we won’t download anything, because we use Build System Maven. We go to the Maven Repository and look for JaCoCo Plugin . We take the latest version and insert the dependency into our pom.xml.

But I don’t recommend doing it through dependencies , because there is a better, more functional alternative, and more than one.
1. Go to CodeCov Setup, select the Java language and select Using JaCoCo plugin, and install according to the instructions.
2. Using the same link , select Using Maven . This option will be even better. Cobertura will extract information from CI tests, but alas, there is a catch. Anything above JDK 7 (and at the moment there is already 10) will not work . Therefore, we will focus on option 1.
As a result, something like this should appear in our pom.xml:
```

<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.8.1</version>
    <executions>
        <execution>
            <goals>
                <goal>prepare-agent</goal>
            </goals>
        </execution>
        <execution>
            <id>report</id>
            <phase>test</phase>
            <goals>
                <goal>report</goal>
            </goals>
        </execution>
    </executions>
</plugin>
```
And in Maven Projects JaCoCo Plugin will appear in the list of plugins:
The plugin is worth it. Everything seems great. But if you carefully read the instructions for installing the JaCoCo plugin, there was an instruction to add a line to .travis.yml responsible for sending the plugin report to the Codecov website .

So, based on Using JaCoCo , we need to write in our file:
```
after_success:
  - bash <(curl -s https://codecov.io/bash)
```
Entered. Great.
Everything seems to be ready, and only the final touches remain. First, let's compile our code and run all the tests, and do it through Lifecycle Maven:

Since we have a test execution phase in the JaCoCo plugin, a report should have appeared after running the Maven test cycle in the target folder:
We are approaching the end. We see that everything works great, all that remains is to make sure that this “everything is fine” will also work on external sources. It's time to put everything together. We assemble the project and push it to GitHub, before opening Travis CI and Codecov to monitor what is happening.

After push we see that the build is successful:

And the result of the JaCoCo plugin about code coverage:
Remember our task? Yes, yes, we forgot about the badge. I wanted to include the topic of “Decoration” of open-source projects in a separate article, but I will still leave a small part here.

So, step-by-step instructions so you don’t get lost:
1. Go to the Codecov website ;
2. Select the project you need;
3. Select Setting:
4. Select Badge and see links to your badge in several different presentation forms:
  
  The first are standard badges; they can be inserted, for example, into your README.md:
  
  Their peculiarity is that when you click on them, you will be redirected to a page with a CC report;
  
  The second are graphs, tables and similar things:

useful links

My test project , which you can download, view, evaluate. Everything about this article is in branch: JaCoCo;
Java Code Coverage Tools ;
JaCoCo Alternatives ;
JaCoCo Library ;
JaCoCo Maven Plugin Dependency ;
Codecov setup tutorial ;
Actually setting up JaCoCo itself ;
Setting up Cobertura ;

There may be errors and omissions in the text. Thank you all for your attention!