# Test validation

After tests have been generated, Cover validates newly created tests by invoking the test phase of your build tool (`Maven`, `Gradle`). Cover will then remove any created tests that fail compilation or execution.

* Existing unit tests must compile **and** pass (`mvn test`, `gradle test`) before `dcover create` is invoked.
* If unvalidated JUnit 5 tests (those which fail to compile or run successfully) are generated by `dcover create`, please confirm that running `mvn test` actually executes your unit tests. JUnit 5 requires at minimum Maven Surefire v2.22.0 to work, and if an older version is present `mvn test` will pass without executing any tests. You can specify the Surefire Plugin version in your POM using:

  ```xml
  <build>
    <plugins>
      <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-surefire-plugin</artifactId>
          <version>2.22.2</version>
      </plugin>
    </plugins>
  </build>
  ```
* When running `mvn test`, `dcover` can disable known style checking plugins (`checkstyle`, `spring-javaformat`) by using the `--ignore-stylechecks` argument.
* Test validation is bypassed if a build tool (`Maven`, `Gradle`) is not detected from your environment. In that case it is possible that some created tests may fail compilation or execution.

## Test Validation and user-specified system properties

The `-D` or `--define` option allows you to pass additional system properties to `dcover` for test creation and execution.

Any created tests *may* depend upon these user-specified system properties and *may not* execute successfully without them.

During test validation `dcover` will forward user-specified system properties to your build tool, be that `Maven` or `Gradle`.

`Maven` is able to utilize these forwarded properties when executing tests for test validation. No configuration is required.

However `Gradle` does not forward system properties to executed tests and will require further configuration to do so. In such a case test validation is likely to fail out-of-the-box without changes to your build script (`build.gradle` or `build.gradle.kts`).

In any case, for `Maven` and `Gradle` you will need to configure test execution in your build script to supply these same user-specified system properties when executing those tests outside `dcover`.

For more details about build tool configuration with system properties, see the [Maven](/features/cover-cli/project-configuration/compiling-your-project/building-a-maven-project.md#maven-and-user-specified-system-properties) and [Gradle](/features/cover-cli/project-configuration/compiling-your-project/building-a-gradle-project.md#gradle-and-user-specified-system-properties) topics.


---

# Agent Instructions: Querying This Documentation

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

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://cover-docs-preview.diffblue.com/features/cover-cli/writing-tests/test-validation.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.