In Go, test coverage is calculated by adding a -cover flag along with a call to a regular call to go test. As this only works for one package at a time, I find this inconvenient. So we are going to use a tool that recursively calculates test coverage for all the packages in a directory tree. This tool is called package-coverage and is available from GitHub (https://github.com/corsc/go-tools/tree/master/package-coverage).

To calculate the coverage using package-coverage, we use the following commands:

$ cd $GOPATH/src/github.com/PacktPublishing/Hands-On-Dependency-Injection-in-Go/ch08/

$ export ACME_CONFIG=$GOPATH/src/github.com/PacktPublishing/Hands-On-Dependency-Injection-in-Go/config.json

$ package-coverage -a -prefix $(go list)/ ./acme/

This gives us the following:

-------------------------------------------------------------------------
|      Branch     |       Dir       |                                   |
|   Cov% |  Stmts |   Cov% |  Stmts | Package                           |
-------------------------------------------------------------------------
|  65.66 |    265 |   0.00 |      7 | acme/                             |
|  47.83 |     23 |  47.83 |     23 | acme/internal/config/             |
|   0.00 |      4 |   0.00 |      4 | acme/internal/logging/            |
|  73.77 |     61 |  73.77 |     61 | acme/internal/modules/data/       |
|  61.70 |     47 |  61.70 |     47 | acme/internal/modules/exchange/   |
|  85.71 |      7 |  85.71 |      7 | acme/internal/modules/get/        |
|  46.15 |     13 |  46.15 |     13 | acme/internal/modules/list/       |
|  62.07 |     29 |  62.07 |     29 | acme/internal/modules/register/   |
|  79.73 |     74 |  79.73 |     74 | acme/internal/rest/               |
-------------------------------------------------------------------------

So, what can we infer from these numbers?

1. The code coverage is reasonable. It could be better but other than the big fat 0 on the logging package, almost all the packages have 50% plus.
2. The statement (stmts) counts are interesting. Statements are roughly equivalent to lines of code, and therefore the numbers indicate which packages have more or less code. We can see that the rest, data, and exchange packages are the largest.
3. We can infer from the amount of code in a package that the more code a package has, the more responsibilities and more complexity it has. By extension, the more risk this package poses.

Given that the two largest, riskiest packages, rest and data, both have good test coverage, we still have nothing that indicates it needs urgent attention. But what happens if we consider the test coverage and dependency graph together?