Code Coverage of Backend Tests in Eight Languages

Intro

0:00 Which lines of your backend did the tests really run? In this video, every run of the test cases answers it : file by file, line by line, in TypeScript, in Python, and in six more languages ; on the page, in your editor, and in CI.

Coverage, the usual way

0:17 Measuring coverage usually means a coverage tool for each language : c8 for Node, coverage dot py, go test dash cover, JaCoCo for Java, each with a report of its own, reports to merge in CI, and code that runs on a server, which is rarely measured at all. With API Maker, one switch : every run of the test cases counts its lines, one report for every language, by the files of your repository, lcov for VS Code and WebStorm, and the numbers in the answer of one API call, for CI.

0:52 In this video : the switch and a run, the report, the lines of a file, two tests for the red lines, Python and its utility classes, how each language counts, npm run test and your editor, and CI.

The switch and a run

1:06 Test Cases is on the dashboard. Delivery Fee, a custom API of Calm Home, has a test case with two tests. At the foot of the list : Collect the code coverage. It is on by default for the runs of this browser, and it slows a run a little. The test case runs Delivery Fee twice : a parcel of two kilos, then one of ten, both in the city.

1:30 Run : two of two pass.

The report

1:32 The Coverage tab of the run. Most of the lines ran, not all. Three files : the custom API Delivery Fee, the utility class pricing slash Rates it uses, and the test case itself. The lowest first : what needs a test is at the top.

The lines of a file

1:49 Delivery Fee, line by line. Green : the lines that ran. Red : the lines no test reached. Missed : lines eight and nine, where a parcel without a weight is refused, and twelve and thirteen, where express doubles the fee. A line without a mark holds no code. And next, pricing slash Rates : the rate of the country never ran either. How the lines of TypeScript are counted : a test run starts the profiler of V8 in the sandbox of the account, the code is compiled again, with a counter on every block, and each count goes back to its line of TypeScript through the source map.

2:29 Counting starts with the run and stops when it ends : the code that serves your API is never changed.

Two tests for the red lines

2:37 Back to the test case. Two tests for the red lines : an express parcel to the country, which costs twice, and a parcel of zero kilos, which is refused. Save, and Run : four of four pass. Every file is at one hundred percent : every line ran.

Python and its utility classes

2:54 Loyalty Points is a custom API written in Python. It takes the tier of a customer from loyalty slash Tiers, a utility class of Python, and its test case is Python too. Run all : six of six pass. Six files, each with the badge of its language. Tiers, in Python : all its lines ran. And then, Loyalty Points : the refusal of an order without a total never ran.

Eight languages

3:22 Every language counts its own lines, in a build made for the test run : TypeScript with the profiler of V8 and the source map, Python with sys dot monitoring, Go with go tool cover, PHP, C sharp and Rust with a counter before each statement, Java and Kotlin with counters written into their compiled classes. Custom APIs, test cases and utility classes : in all eight languages, in one report.

Clear coverage

3:50 Clear coverage removes the coverage of the last run ; its results stay. Clear results removes both. The last run is kept thirty days, so the page shows it again after a reload.

npm run test

4:03 In the folder of the local client, npm run test runs the same tests on the server, and prints the coverage of every file. It writes coverage slash lcov dot info, with the paths of your files : Coverage Gutters in VS Code, or Show Coverage Data in WebStorm, mark the lines in your editor.

In CI

4:23 For CI, a run is one call : POST run, with coverage true. The answer holds the results, and the coverage of every file with its totals. npm run test exits with zero when everything passed, and writes coverage-summary dot json in the shape istanbul uses, so a job can hold a floor of coverage.

Good to know

4:44 Good to know. A sandbox on Bun has no profiler : the run says so, and counts no TypeScript. Java and Kotlin count their lines on JDK twenty four and later. Hooks, events and schedulers that ran during the tests are named in a warning, not counted. And a very large report is kept with its totals only, until the next run.

Best practices

5:08 Best practices. Read the red lines, not only the percentage : each one is a case no test checks. Mock g dot sys to reach the paths of errors. Keep coverage on in CI, with a floor. And run the tests after every change : the next run shows what the change left untested.

Recap

5:28 To sum up. One switch, and every run of the test cases counts its lines. The report lists every file : the test cases, the custom APIs they ran, the utility classes they used. Red lines show what no test reached. Eight languages, each counted its own way. npm run test brings it to your editor and to CI. Next : debugging, from a failing call to the line that broke.

5:55 API Maker. Build faster, spend smarter, deliver better.