> For the complete documentation index, see [llms.txt](https://docs.sonarsource.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sonarsource.com/sonarqube-cloud/analyzing-source-code/test-coverage/generic-test-data.md).

# Generic test data

This page describes how generic data should be formatted when you want to import it into your SonarQube Cloud test coverage and test execution reports.

SonarQube Cloud supports a generic format for importing test coverage and test execution reports. This feature can help you integrate a tool that is not directly supported by SonarQube Cloud by having your custom CI task convert the output of the unsupported tool to this generic format, which can then be imported into SonarQube Cloud.

## Generic coverage <a href="#generic-coverage" id="generic-coverage"></a>

Report paths should be passed in a comma-delimited list to:

* `sonar.coverageReportPaths`

The supported format is described by the `sonar-generic-coverage.xsd`:

```xml
<xs:schema>
  <xs:element name="coverage">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="file" minOccurs="0" maxOccurs="unbounded">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="lineToCover" minOccurs="0" maxOccurs="unbounded">
                <xs:complexType>
                  <xs:attribute name="lineNumber" type="xs:positiveInteger" use="required"/>
                  <xs:attribute name="covered" type="xs:boolean" use="required"/>
                  <xs:attribute name="branchesToCover" type="xs:nonNegativeInteger"/>
                  <xs:attribute name="coveredBranches" type="xs:nonNegativeInteger"/>
                </xs:complexType>
              </xs:element>
            </xs:sequence>
          <xs:attribute name="path" type="xs:string" use="required"/>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
      <xs:attribute name="version" type="xs:positiveInteger" use="required"/>
    </xs:complexType>
  </xs:element>
</xs:schema>
```

and looks like this:

```xml
<coverage version="1">
  <file path="xources/hello/NoConditions.xoo">
    <lineToCover lineNumber="6" covered="true"/>
    <lineToCover lineNumber="7" covered="false"/>
  </file>
  <file path="xources/hello/WithConditions.xoo">
    <lineToCover lineNumber="3" covered="true" branchesToCover="2" coveredBranches="1"/>
  </file>
</coverage>
```

The root node should be named `coverage`. Its version attribute should be set to `1`.

Insert a `file` element for each file which can be covered by tests. Its `path` attribute can be either absolute or relative to the root of the module. Inside a `file` element, insert a `lineToCover` for each line which can be covered by unit tests. It can have the following attributes:

* `lineNumber` (mandatory)
* `covered` (mandatory): boolean value indicating whether a test hits that line
* `branchesToCover` (optional): number of branches that can be covered
* `coveredBranches` (optional): number of branches that are covered by tests

## Generic execution <a href="#generic-execution" id="generic-execution"></a>

Report paths should be passed in a comma-delimited list to:

* `sonar.testExecutionReportPaths`

The supported format looks like this:

```xml
<testExecutions version="1">
  <file path="testx/ClassOneTest.xoo">
    <testCase name="test1" duration="5"/>
    <testCase name="test2" duration="500">
      <skipped message="short message">other</skipped>
    </testCase>
    <testCase name="test3" duration="100">
      <failure message="short">stacktrace</failure>
    </testCase>
    <testCase name="test4" duration="500">
      <error message="short">stacktrace</error>
    </testCase>
  </file>
</testExecutions>
```

The root node should be named `testExecutions`. Its version attribute should be set to `1`.

Insert a `file` element for each test file. Its `path` attribute can be either absolute or relative to the root of the module.

**Note** unlike for coverage reports, the files present in the report must be test file names, not source code files covered by tests.

Inside a `file` element, insert a `testCase` for each test run by unit tests. It can have the following attributes/children:

* `testCase` (mandatory)
  * `name` (mandatory): name of the test case
  * `duration` (mandatory): long value in milliseconds
  * `failure|error|skipped` (optional): if the test is not OK, report the cause with a message and a long description
    * `message` (mandatory): short message describing the cause
    * `stacktrace` (optional): long message containing details about `failure|error|skipped` status


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.sonarsource.com/sonarqube-cloud/analyzing-source-code/test-coverage/generic-test-data.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.