Data validation looks at one file on its own. The system-level module goes further and tests how your DPP System behaves in a network of DPP participants. The testing environment simulates that network and runs predefined test scenarios against the standardized Lifecycle API.
A scenario can check, for example, whether your system answers a passport data request from another actor correctly, whether it returns the data in the expected format and whether it handles errors as the specification requires.
Each passport data request is sent with a specific access role, such as an authority or a notified body. The access rights are defined per data field: a role only gets the fields it may see and can only change the fields it may change.
There are three system roles:
Your system is connected through two interfaces: the Lifecycle API, which your DPP System exposes, and a Test Adapter, a small component that prepares and cleans up your system for the tests.
The environment comes with example interfaces, so you can run a complete test before you connect your own system. That way you get to know the test flow before you invest time in the integration.
Sign in and open the Configuration Page. You have to fill in the following:
System role: Choose whether your system acts as Economic Operator, Backup Provider or Main Service Provider in this run.
Lifecycle API version: Choose whether the run targets version v1 of the standard or the draft. With v1, the testing environment adds /v1 to the Lifecycle API base URL you entered. With the draft, the URL is used as it is. If your URL already ends with a version, it has to match your choice, otherwise the run is blocked.
Profile: The profile determines which BatteryPass the test cases run with: its schema, sample battery passports and access rights, for example which role may read and change which data element. The bundled templates cover the supported battery categories. Under My profiles you can create your own profiles based on them. Pick the profile that fits your system before you start a run. It stays selected when you reload the page.
Lifecycle API base URL: The address under which your DPP System receives requests from other DPP participants. For a first run without your own system, use the example:
https://batterypass-ready.gefeg.com/economic-operator/api/Test Adapter base URL: The address of the adapter that prepares and cleans up your DPP System for the tests. For a first run, use:
https://batterypass-ready.gefeg.com/test-adapter/api/Every test run gets its own result page with an overview, filters and the configuration used. From there you can copy a result or download it as a JSON file, or download the entire run as a ZIP archive. Credentials and tokens are redacted in the logs, so you can share results without cleaning them up first.
Your earlier runs are kept in the test run history. There you can filter them, reopen them or delete them.
A response with an unexpected status code counts as a failed check, not as an error in the test run itself. If you switch the system role, the results and selections of the previous run are reset.
The conformance check runs all test cases of your system role. If your system passes, you receive a test report by email and as a PDF to download.
You can change the configuration and run any test case again as often as you like.
The testing environment talks to your DPP System over two separate channels.
The TestExecutor calls the Lifecycle API of your DPP System directly, using the interfaces defined in the standard. This is the main test channel. It sends the same API requests that real DPP participants would send in production.
The Test Adapter is a small, separate component that is only used for testing. Before each test case, the TestExecutor calls it to put your system into the state the test needs, for example by inserting test passports or issuing test credentials. After the test, the TestExecutor calls it again to clean up and reset your system.
The Test Adapter is not part of your production system and only runs during tests. Its job is to set your system up before each test and to restore a clean state afterwards. Because of this, the tests can run fully automatically, and you can also include them in a CI/CD pipeline.
The Test Adapter must expose two endpoints:
PUT /TestSetupCalled before each test case. The request body contains a list of setup commands that put your system into the state the test needs. These command types are supported:
| Command | Purpose |
|---|---|
insertBatteryPass | Create a battery passport record in your DPP System |
bringBatteryToMarket | Mark a passport as “placed on the market” |
issueCredentials | Generate test access credentials (API key or JWT) for the testing environment to authenticate against your Lifecycle API |
For the role parameter of issueCredentials, the seven battery passport access roles are used: public, economic_operator, notified_bodies, authorities, commission, legitimate_interest and third_parties_authorized_by_economic_operator.
For the Main Service Provider system role, issueCredentials can also contain the optional field economicOperatorId. It ties the issued credentials to one economic operator, so the testing environment can check that your system refuses access to the passports of other economic operators with 403.
Example request body:
{
"commands": [
{
"type": "insertBatteryPass",
"parameters": {
"passportId": "urn:batterypass:example:001",
"data": { ... }
}
},
{
"type": "issueCredentials",
"parameters": {
"credentialType": "apiKey",
"role": "public"
}
}
]
}Your adapter should work through the commands one after the other, carry out the matching operations in your DPP System and report back for each command whether it succeeded or failed. If your adapter rejects even a single command, the test setup is shown as failed.
PUT /TestTeardownCalled after each test case. The adapter should bring your system back to the state it was in before the test case. How you do that depends on your system. Restoring a database snapshot is one common way.
A reference adapter implementation (including the OpenAPI/YAML specification) is available in the Resources section.