Do I have to change my source code or build system?

No. You add rktracer as a prefix to your existing make or build command, or enable the plugin in your IDE. There are no source edits, no environment variables and no wrappers. RKTracer instruments at compile time and links its runtime library automatically, even when cross-compiled.

RKTracer · How code coverage works

How RKTracer measures code coverage

This is how code coverage works inside RKTracer: it takes the preprocessed source from your compiler, inserts tracking code at compile time, links a runtime library automatically, and collects coverage while your tests run, without changing a single line of your source code. The result is a color-coded report through MC/DC.

Download Free Trial Book a Demo

Compile-time instrumentation · auto-linked runtime · HTML and XML reports

terminal · the whole workflow

# 1. Prefix your existing build command
$ rktracer make
  auto-detecting compiler: arm-none-eabi-gcc 12.2
  instrumenting preprocessed source: 142 files…
  linking rktracer runtime library…
  ✓ build complete, source unchanged

# 2. Run tests, then generate the report
$ ctest && rkresults --report html
  ✓ statement 100% · decision 100% · MC/DC 99.2%

What RKTracer is

A code coverage tool, explained from the inside

RKTracer is a code coverage tool that measures how much of your source code your tests actually execute, from function and statement coverage all the way up to MC/DC. This page explains how code coverage works inside RKTracer, step by step, so you can see exactly what happens to your build, your binary and your test run.

The short version: you prefix your build command or enable an IDE plugin, RKTracer performs code coverage instrumentation on the preprocessed source at compile time, a runtime library is linked in automatically, coverage is collected while your tests run on whatever target you ship, and the rkresults command turns the data into color-coded HTML and XML reports. No source edits, no wrappers, no environment variables. The sections below walk through each part of that pipeline.

The workflow

How code coverage works in five steps

From your unmodified build command to an evidence-grade report, this is the full RKTracer pipeline.

Build integration

Enable the plugin in your IDE, such as Visual Studio, Eclipse, IAR or CCS, or add rktracer as a prefix to your make or build command in the terminal. RKTracer auto-detects your compiler.

Code instrumentation

RKTracer takes the preprocessed source files from the compiler and inserts tracking code that records which parts of your code run, then passes the result back to the compiler. Your source files are never modified.

Runtime library

RKTracer includes a runtime library that is linked into the build automatically. It ensures coverage data is collected even on embedded devices, simulators or servers.

Test execution

Run your unit, integration, functional and system tests as you already do. RKTracer collects coverage data live while tests run on a host, target device, simulator or server.

Report generation

Run the rkresults command to generate HTML reports, easy to view in a web browser, and XML reports for CI/CD tools and SonarQube. Reports from multiple runs can be merged.

two commands, start to finish

# Build with instrumentation, no source change
$ rktracer make
  ✓ instrumented and built

# Run tests, then generate the report
$ ./run_tests
$ rkresults --report html
  ✓ coverage report written to ./rkresults/index.html

Follow the step-by-step guides for CMake, Makefile, IAR Embedded Workbench, Visual Studio and 30+ more toolchains.

How instrumentation works

Code coverage instrumentation at compile time

The heart of how code coverage works in RKTracer is its instrumentation stage. It sits inside the compile step, transparently, so your build command and your source tree stay exactly as they were.

Preprocessed source, not your files. RKTracer takes the preprocessed source the compiler has already produced, so macros and includes are fully expanded and nothing on disk is touched.
Tracking code inserted. Lightweight probes are added at each statement, decision, condition and MC/DC point so the runtime can record what executes.
Back to the compiler. The instrumented source is handed straight back to your real compiler, so your optimization flags, standard and target stay intact.
Runtime auto-linked. The RKTracer runtime library is added to the link automatically, even when you cross-compile for a different architecture.

Because instrumentation happens on preprocessed source and the runtime links itself, there are no source edits, no wrappers and no environment variables to manage.

Instrumentation pipelinecompile time

Your source

Untouched on disk.

Compiler preprocess

Macros and includes expanded.

RKTracer inserts probes

Statement, decision, condition, MC/DC.

Compiler builds object

Your real flags and target.

Runtime linked in

Automatic, even cross-compiled.

Where coverage data goesruntime

Host or server: written straight to a coverage file.
Target with a file system: same, written on the device.
Target without a file system: streamed over the debug transport.
Constrained target: buffered in RAM, retrieved at end of run.
Host merges every source into one unified report.

Capture on any target

Coverage even where there is no file system

The runtime library is what makes RKTracer work on real hardware, not just a desktop build. It is small, it is linked automatically, and it knows how to get coverage data off the device whatever the device is.

On a host machine, simulator or server, the runtime writes coverage to a file. On a deeply embedded target that has no file system, the runtime instead streams the data out over your existing debug transport, such as a JTAG or serial link, or buffers it in a small region of RAM that the host reads back when the run finishes. Either way, the host side reassembles the data into the same coverage model and the same color-coded report you get on a laptop, so one coverage tool covers your whole stack.

This is the same instrumentation and the same metrics across host, embedded, GPU and simulator. You learn it once.

Metrics and reports

Every metric, color-coded to the line

RKTracer measures the full set of structural metrics and renders them so a gap is obvious at a glance.

Function & File

Which functions and files your tests reach.

Line, Statement & Branch

Every statement runs and both outcomes of each decision are tested.

Condition & MC/DC

The strongest structural metrics. MC/DC is measured natively for C and C++.

Multi-Condition & Delta

Go beyond MC/DC, and focus coverage on exactly what changed each build.

Color-coded reports you can read instantly

The rkresults command renders coverage as HTML for browsing and XML for CI/CD and SonarQube. Every line and decision is color-coded:

Green: fully covered.
Yellow / amber: partially covered.
Red: not covered.

RKValidate is an ISO 9001 quality-certified vendor. RKTracer measures the coverage metrics that standards such as DO-178C, ISO 26262 and IEC 61508 reference; it does not itself carry a functional-safety certification.

Coverage report · flight_law.cMC/DC measured

Function100%

Statement100%

Decision100%

Condition100%

MC/DC99%

Multi-condition94%

HTML for review, XML for CI and SonarQube. Merge reports across multiple runs.

Where it runs

One code coverage tool across your whole stack

Targets

Host machines & servers
Embedded (with/without FS)
GPUs & CUDA
Simulators & emulators

Languages

10 languages, one coverage model:

CC++CUDARustC#JavaJavaScriptTypeScriptGoPython

MC/DC is measured for C and C++.

Build systems

GNU Makefile & CMake
MSBuild, Maven, Ant, Bazel
Gradle & NDK build
All compilers & cross-compilers

IDEs & CI

Visual Studio, Eclipse
IAR, Keil, CCS, Android Studio
Jenkins, Azure DevOps, GitLab
Publishes to SonarQube

See the full features and metrics, the RKTracer overview, or browse all 33 documentation guides.

From coverage to tests

Coverage finds the gaps. Two ways to close them.

Once RKTracer shows how code coverage works on your build, it pinpoints the uncovered lines, decisions and MC/DC conditions. Turning those gaps into tests is your choice, and both options are part of the RKTracer tool.

RKTracer itself measures coverage; it does not generate tests. The two tools below do.

Compare RKMCP and RKTracerGen

RKMCP · AI-assisted

An MCP server that streams the uncovered code to your AI agent as JSON-RPC. The AI writes unit and functional tests plus the build, then runs and re-checks until the gaps close.

RKTracerGen · offline

A deterministic, fully offline unit-test generator. Boundary-Value Analysis, real-run oracle, managed stubs and a standalone build. No AI, no tokens, no network.

FAQ

How code coverage works: questions answered

Code coverage works by instrumenting your program so it records which parts execute. A code coverage tool inserts tracking code, runs your tests, and counts which lines, branches and conditions ran. RKTracer takes the preprocessed source from the compiler, inserts tracking code at compile time, links a runtime library automatically, collects data while tests run, and then generates color-coded HTML and XML reports through MC/DC.

RKTracer takes the preprocessed source files from the compiler, adds instrumentation code that tracks which parts execute, and passes the result back to the compiler. Your original source files on disk are never modified. The code coverage instrumentation happens at compile time, transparently, after you prefix your build command or enable the IDE plugin.

No. You add rktracer as a prefix to your existing make or build command, or enable the plugin in your IDE. No source edits, no environment variables, no wrappers. RKTracer instruments at compile time and links its runtime library automatically, even when cross-compiled.

RKTracer links a small runtime library into the build. On a target with no file system, that runtime streams coverage data out over your existing debug transport, such as a JTAG or serial link, or buffers it in RAM for retrieval at the end of the run. The host then merges it into the same report you get on a desktop build.

Ten languages: C, C++, CUDA, Rust, C#, Java, JavaScript, TypeScript, Go and Python. RKTracer auto-detects all compilers and cross-compilers and works with GNU Makefile, CMake, MSBuild, Gradle and NDK, Maven, Ant and Bazel, plus IDE plugins for Visual Studio, Eclipse, IAR, Keil uVision, Code Composer Studio and Android Studio.

Green means fully covered, yellow or amber means partially covered, and red means not covered. The reports are generated by the rkresults command as HTML for browsing and XML for CI/CD tools and SonarQube. Reports from multiple runs can be merged.

RKTracer measures coverage and pinpoints the uncovered lines, decisions and MC/DC conditions; it does not generate tests itself. To close the gaps you can use RKMCP, which serves the gaps to your AI agent over MCP so it writes unit and functional tests, or RKTracerGen, a deterministic offline unit-test generator that uses Boundary-Value Analysis and managed stubs. Both are part of the RKTracer tool.

See how code coverage works on your own code

Download the free 30-day trial and run the full workflow on your target today, or book a 30-minute demo with an engineer.

Download Free Trial Book a Demo