Product
Solutions
Resources
Company
Download Trial Book a Demo
RKTracer · Web & UI test coverage

Code coverage for web and UI tests, Selenium-ready

RKTracer measures real web and UI test coverage from your Selenium and WebDriver runs, from statement and branch to condition and MC/DC, across JavaScript, TypeScript and the server side. No test rewrites, no new framework.

Wrap your existing suite · HTML and XML reports · publishes to SonarQube

terminal · selenium coverage
# Enable RKTracer on your existing build, no test rewrites
$ rktracer -ec -integrate
  instrumenting application under test…

# Run your Selenium suite exactly as today
$ mvn clean && mvn test
  launching chromedriver · 184 UI scenarios…
   suite green, coverage captured

$ rktracer report
   statement 100% · decision 100% · condition 97%
Why UI and E2E tests leave blind spots

A green Selenium run proves it clicks, not what it covered

End-to-end and UI suites are written from the outside in. They open a page, fill a form, click a button and assert on what the screen shows. When the run is green you know the journeys you scripted behaved, but you do not know which statements, branches, conditions and decisions in the code behind the interface actually ran. That gap is exactly where web and UI test coverage lives.

The risk is concentrated in the logic the UI never reached: a validation branch for a malformed input, an error path for a failed API call, a permissions check that only one role triggers. A passing screenshot says nothing about those paths. Without coverage you cannot tell a thoroughly exercised feature from one that happened to render. RKTracer closes that gap by recording, from the same run, every line and decision the application executed, so a passing suite turns into measured evidence instead of a hopeful guess.

This blind spot grows as suites scale. Teams add scenarios to chase confidence, and the run gets slower, yet two suites with very different reach can both report green. The honest question is not how many tests pass but how much of the application they touch, and where the untouched code is. Coverage answers it directly: it ranks the files and decisions your UI tests never reach, so you spend new test effort where it removes real risk rather than re-walking paths that are already exercised many times over.

Turning Selenium into real coverage

From a passing UI suite to Selenium code coverage

RKTracer instruments the application under test, then your Selenium or WebDriver suite runs unchanged. As the browser drives the UI, RKTracer records which code the application executes, so the same run that proves the journey also measures the coverage behind it.

The workflow is three steps and uses the build you already have. Enable RKTracer with the IDE plugin, run your suite through Maven the way you run it today, and generate the report. Nothing about how your tests are written changes, and a config file lets you scope coverage to the folders that matter.

Because the coverage rides along with the suite you already run, there is no second pipeline to maintain and no separate instrumented build to keep in sync. The same WebDriver session that opens the browser, fills the forms and asserts on the result also produces the coverage record, so every regression run leaves behind a measurable trail of what the application did. Cross-browser and headless runs in CI work the same way, which means the coverage you read in a pull request reflects the exact behaviour your reviewers care about.

Read the Selenium and Eclipse guide
1

Enable and rebuild

Run rktracer -ec -integrate to add the plugin, then turn RKTracer on for the project. It instruments the application under test as the build runs. Your source is never edited.

2

Run your Selenium suite

Run mvn clean then mvn test as you do today. WebDriver drives the browser through your existing scenarios, and RKTracer captures coverage live.

3

Generate the report

One command emits the RKTracer Report as HTML and XML, ready for dashboards, CI gating and SonarQube. Merge reports across runs to combine suites.

How RKTracer instruments the app under test

JavaScript and TypeScript on the front end, your language on the server

RKTracer instruments at build time and adds its runtime automatically, so one coverage model spans the whole web stack.

A modern web feature is rarely a single layer. A click in the browser runs front-end JavaScript or TypeScript, calls an API, and triggers a chain of server-side logic before anything returns to the screen. RKTracer instruments both ends in the same pass and stitches the results into one report, so you can follow a single UI scenario from the code that handled the click to the decision deep in the service that shaped the response.

Front end: JavaScript & TypeScript

RKTracer measures JavaScript code coverage and TypeScript code coverage for the code that runs in the browser, so the front-end behaviour your UI tests exercise is recorded as statement, branch and condition coverage.

Server side, same model

The code behind the API is instrumented in the same pass. Whether the service is Java, C#, Python, Go, C or C++, RKTracer applies one consistent coverage model end to end across the request path.

Scoped, no source edits

An rktracer.config file scopes instrumentation by folder, so you can include the application modules and skip generated or vendor code. There are no source changes and no environment variables.

See the step-by-step guides for Selenium with Java and Eclipse and JavaScript and TypeScript, or browse all 33 toolchain guides.

Every metric, through MC/DC

JaCoCo-style numbers, plus the structural metrics they stop short of

RKTracer reports the function, line and statement coverage teams expect from JaCoCo-style tools, then goes further: branch, decision and condition coverage on every web stack, and MC/DC and multi-condition coverage for C and C++. Delta coverage focuses each run on exactly what changed.

  • Per-file and per-method drill-down across the app
  • Branch, decision and condition coverage from one run
  • MC/DC and multi-condition for C and C++
  • Gate the build below a coverage threshold

RKValidate is an ISO 9001 quality-certified vendor. RKTracer measures the coverage metrics that assurance workflows reference; it does not itself carry a functional-safety certification.

RKTracer Report · checkout-webSelenium run
Function100%
Statement100%
Decision100%
Condition97%
Branch96%

184
UI scenarios
312
files covered
0
test rewrites
Host, browser & CI

One coverage model across your whole web stack

Where it runs

  • Host machines & servers
  • Chrome, Firefox & WebDriver browsers
  • Headless runs in CI containers
  • Front end & server in one report

Languages

Front end and server, one model:

JavaScriptTypeScriptJavaC#PythonGoCC++Rust

Ten languages in all, including CUDA. MC/DC and multi-condition apply to C and C++.

Build & CI

  • Maven & Eclipse plugin
  • Jenkins, Azure DevOps, GitLab CI
  • HTML & XML reports
  • Publishes to SonarQube
CI & SonarQube

Coverage that gates the build and lands in your dashboard

Because RKTracer hooks the build you already run, the Selenium suite collects coverage in the same pass it already takes. In CI the report becomes a gate: fall below your statement, decision or condition threshold and the build fails.

RKTracer publishes HTML and XML, runs in Jenkins, Azure DevOps and GitLab CI, and publishes coverage to SonarQube so web and UI test coverage sits beside the rest of your quality signals. Reports from several Selenium runs merge into one view, so smoke, regression and cross-browser suites combine into a single coverage picture.

See the CI and SonarQube guides
CapabilityTypical web coverage toolRKTracer
Statement & lineYesYes
Works with Selenium runsYesYes
Decision & conditionPartialNative
MC/DC (C and C++)NoYes
Front end & server, one reportRareYes
Delta / changed-codeRareYes
Reports & CIVariesHTML / XML, SonarQube, all major CI

Comparison reflects common capabilities of mainstream web coverage tools; individual tools vary.

FAQ

Web and UI test coverage questions, answered

Web and UI test coverage measures how much of your application code your browser-driven tests actually execute. A passing Selenium or WebDriver run proves the interface behaved, but only coverage shows which statements, branches, conditions and decisions in the code behind the UI really ran. RKTracer captures that coverage from the same run.
Yes. RKTracer instruments the application under test, then your suite runs unchanged. For a Java back end you enable it with the IDE plugin (rktracer -ec -integrate), run mvn clean and mvn test as you do today with WebDriver driving the browser, and coverage is captured live. No test rewrites, no new framework.
Yes. RKTracer measures JavaScript code coverage and TypeScript code coverage for the front-end code that runs in the browser, and it measures the server-side languages behind the API in the same model. You see one coverage report across the whole web stack.
Function, file, statement, branch/decision and condition, plus delta coverage on changed code. For C and C++ you also get MC/DC and multi-condition. You get the line and statement numbers teams expect from JaCoCo-style tools, and the deeper structural metrics they stop short of.
No. RKTracer instruments at build time and adds its runtime automatically. You enable it on your existing Maven or IDE build, and an rktracer.config file lets you scope coverage to specific folders. There are no source edits and no test changes.
Yes. RKTracer publishes HTML and XML reports, runs in Jenkins, Azure DevOps and GitLab CI, and publishes coverage to SonarQube. You can gate the build below a coverage threshold and merge reports from multiple Selenium runs.

Turn your Selenium runs into measured coverage

Download the free 30-day trial and run RKTracer on your own web app today, or book a 30-minute demo with a coverage engineer.