Skip to content
Codevidence Docs

Reference — Verified Available now

@VerifiesControl

@VerifiesControl marks a JUnit 5 test as the thing that confirms a Declared control actually behaves as claimed. The test calls a typed assertion from ComplianceAssertions, and Codevidence records whether it passed or failed as a Verified evidence record.

Fields

Field Type Required Description
id String Yes Must match the id of an existing @ComplianceControl — this is what links the test back to the Declared control it verifies.

Usage

Verifying the consent.capture control declared in the @ComplianceControl reference. No @ExtendWith — the JUnit extension is picked up automatically (see setup below):

ConsentServiceTest.java 
import com.codevidence.annotations.VerifiesControl;
import com.codevidence.assertions.ComplianceAssertions;
import org.junit.jupiter.api.Test;

class ConsentServiceTest {

    @VerifiesControl(id = "consent.capture")
    @Test
    void consentIsRecordedWithLawfulBasis() {
        var service = new ConsentService();
        service.recordConsent("user-42");

        ComplianceAssertions.assertConsentRecorded("user-42", "consent");
    }
}

Setup

Add the assertions library as a test dependency:

pom.xml 
<dependency>
    <groupId>com.codevidence</groupId>
    <artifactId>codevidence-assertions</artifactId>
    <version>0.1.0</version>
    <scope>test</scope>
</dependency>

Enable JUnit Platform extension auto-detection so the test only needs @VerifiesControl + @Test:

junit-platform.properties 
# src/test/resources/junit-platform.properties
junit.jupiter.extensions.autodetection.enabled=true

Point the test runner at the directory where per-assertion findings are written, so the build plugin can read them back afterward — Surefire and the Gradle test task run in a forked JVM, so this handoff is a directory, not shared memory. See build plugin configuration for the exact Maven and Gradle snippets.

How it works

@VerifiesControl has RUNTIME retention (a test has to actually run for its assertions to pass or fail), so unlike @ComplianceControl it's read by reflection, not by scanning bytecode. An auto-registered JUnit 5 extension tracks which @VerifiesControl test is running; every ComplianceAssertions call inside it is recorded as a raw finding — pass or fail, because an auditor needs to see a broken control as much as a working one.

After the test phase, the build plugin (report-verified-evidence for Maven, reportVerifiedEvidence for Gradle) reads those findings, attaches the same provenance as a Declared record (commit, build, timestamp), and writes one Verified evidence record per finding to target/codevidence/verified/. Nothing about your production code runs — only your own tests, in your own pipeline.

Next