Die Datenvalidierung betrachtet eine einzelne Datei für sich. Der Systemtest geht weiter und prüft, wie sich Ihr DPP-System in einem Netzwerk von DPP-Teilnehmern verhält. Die Testumgebung simuliert dieses Netzwerk und führt vordefinierte Testszenarien gegen die standardisierte Lifecycle API aus.
Ein Szenario kann zum Beispiel prüfen, ob Ihr System eine Passport-Datenanfrage eines anderen Akteurs korrekt beantwortet, ob es die Daten im erwarteten Format liefert und ob es Fehlerfälle so behandelt, wie es die Spezifikation vorsieht.
Jede Passport-Datenanfrage wird in einer bestimmten Zugriffsrolle gestellt, etwa als Behörde oder als notifizierte Stelle. Die Zugriffsrechte sind je Datenfeld festgelegt: Eine Rolle erhält nur die Felder, die sie sehen darf, und kann nur die Felder ändern, für die sie berechtigt ist.
Es gibt drei Systemrollen:
Ihr System wird über zwei Schnittstellen angebunden: die Lifecycle API, die Ihr DPP-System bereitstellt, und einen Test-Adapter, eine kleine Komponente, die Ihr System für die Tests vorbereitet und danach wieder aufräumt.
Die Umgebung bringt Beispiel-Schnittstellen mit, sodass Sie einen vollständigen Test durchführen können, bevor Sie Ihr eigenes System anbinden. So lernen Sie den Ablauf kennen, ohne vorher Zeit in die Integration zu stecken.
Melden Sie sich an und öffnen Sie die Configuration Page. Folgendes müssen Sie angeben:
Systemrolle: Wählen Sie, ob Ihr System in diesem Lauf als Economic Operator, Backup Provider oder Main Service Provider auftritt.
Version der Lifecycle API: Wählen Sie, ob gegen Version v1 der Norm oder gegen den Entwurfsstand getestet wird. Bei v1 hängt die Testumgebung /v1 an die eingegebene Lifecycle API Base URL an. Beim Entwurfsstand wird die URL so verwendet, wie sie ist. Endet Ihre URL schon auf eine Version, muss sie zur Auswahl passen, sonst wird der Lauf gesperrt.
Profil: Das Profil bestimmt, mit welchem BatteryPass die Testfälle ausgeführt werden: Schema, Beispiel-Batteriepässe und Zugriffsrechte, also zum Beispiel welche Rolle welches Datenelement lesen und ändern darf. Die mitgelieferten Vorlagen decken die unterstützten Batteriekategorien ab. Unter Meine Profile können Sie darauf aufbauend eigene Profile anlegen. Wählen Sie vor dem Start das Profil, das zu Ihrem System passt. Es bleibt auch nach dem Neuladen der Seite ausgewählt.
Lifecycle API Base URL: Die Adresse, unter der Ihr DPP-System Anfragen anderer DPP-Teilnehmer entgegennimmt. Für einen ersten Lauf ohne eigenes System verwenden Sie das Beispiel:
https://batterypass-ready.gefeg.com/economic-operator/api/Test Adapter Base URL: Die Adresse des Adapters, der Ihr DPP-System für die Tests vorbereitet und aufräumt. Für einen ersten Lauf verwenden Sie:
https://batterypass-ready.gefeg.com/test-adapter/api/Jeder Testlauf bekommt eine eigene Ergebnisseite mit Übersicht, Filtern und der verwendeten Konfiguration. Dort können Sie ein Ergebnis kopieren oder als JSON-Datei herunterladen oder den gesamten Lauf als ZIP-Archiv speichern. Zugangsdaten und Tokens werden in den Protokollen unkenntlich gemacht, Sie können Ergebnisse also weitergeben, ohne sie vorher bereinigen zu müssen.
Ihre früheren Läufe bleiben im Verlauf erhalten. Dort können Sie sie filtern, erneut öffnen oder löschen.
Eine Antwort mit einem unerwarteten Statuscode zählt als nicht bestandene Prüfung und nicht als Fehler im Testablauf selbst. Wechseln Sie die Systemrolle, werden Ergebnisse und Auswahl des vorherigen Laufs zurückgesetzt.
Starten Sie die Konformitätsprüfung für Ihre Systemrolle. Besteht Ihr System die Prüfung, erhalten Sie einen Prüfbericht per E-Mail und als PDF zum Herunterladen.
Sie können die Konfiguration jederzeit ändern und jeden Testfall beliebig oft erneut ausführen.
Die Testumgebung spricht über zwei getrennte Kanäle mit Ihrem DPP-System.
Der TestExecutor ruft die Lifecycle API Ihres DPP-Systems direkt auf, über die in der Norm festgelegten Schnittstellen. Das ist der Hauptkanal der Tests. Er sendet dieselben API-Anfragen, die echte DPP-Teilnehmer im Produktivbetrieb senden würden.
Der Test-Adapter ist eine kleine, eigene Komponente, die nur für Tests verwendet wird. Vor jedem Testfall ruft der TestExecutor ihn auf, um Ihr System in den Zustand zu bringen, den der Test braucht, zum Beispiel indem Test-Passports angelegt oder Test-Zugangsdaten ausgestellt werden. Nach dem Test ruft der TestExecutor ihn erneut auf, um aufzuräumen und Ihr System zurückzusetzen.
Der Test-Adapter gehört nicht zu Ihrem Produktivsystem und läuft nur während der Tests. Seine Aufgabe ist es, Ihr System vor jedem Test vorzubereiten und danach wieder in einen sauberen Zustand zu versetzen. Dadurch können die Tests vollautomatisch laufen, und Sie können sie auch in eine CI/CD-Pipeline einbinden.
Der Test-Adapter muss zwei Endpunkte bereitstellen:
PUT /TestSetupWird vor jedem Testfall aufgerufen. Der Request Body enthält eine Liste von Setup-Kommandos, die Ihr System in den Zustand versetzen, den der Test braucht. Diese Kommandotypen werden unterstützt:
| Kommando | Zweck |
|---|---|
insertBatteryPass | Einen Battery-Passport-Datensatz in Ihrem DPP-System anlegen |
bringBatteryToMarket | Einen Passport als „in Verkehr gebracht“ markieren |
issueCredentials | Test-Zugangsdaten erzeugen (API Key oder JWT), mit denen sich die Testumgebung gegenüber Ihrer Lifecycle API authentifizieren kann |
Für den Parameter role von issueCredentials werden die sieben Zugriffsrollen des Batteriepasses verwendet: public, economic_operator, notified_bodies, authorities, commission, legitimate_interest und third_parties_authorized_by_economic_operator.
Für die Systemrolle Main Service Provider kann issueCredentials außerdem das optionale Feld economicOperatorId enthalten. Es bindet die ausgestellten Zugangsdaten an einen Wirtschaftsakteur, damit die Testumgebung prüfen kann, ob Ihr System den Zugriff auf Pässe anderer Wirtschaftsakteure mit 403 abweist.
Beispiel-Request-Body:
{
"commands": [
{
"type": "insertBatteryPass",
"parameters": {
"passportId": "urn:batterypass:example:001",
"data": { ... }
}
},
{
"type": "issueCredentials",
"parameters": {
"credentialType": "apiKey",
"role": "public"
}
}
]
}Ihr Adapter sollte die Kommandos nacheinander abarbeiten, die passenden Operationen in Ihrem DPP-System ausführen und für jedes Kommando zurückmelden, ob es erfolgreich war oder fehlgeschlagen ist. Lehnt Ihr Adapter auch nur ein einzelnes Kommando ab, wird die Testvorbereitung als fehlgeschlagen angezeigt.
PUT /TestTeardownWird nach jedem Testfall aufgerufen. Der Adapter soll Ihr System wieder in den Zustand bringen, den es vor dem Testfall hatte. Wie Sie das umsetzen, hängt von Ihrem System ab. Die Wiederherstellung eines Datenbank-Snapshots ist ein gängiger Weg.
Eine Referenz-Implementierung des Adapters (einschließlich der OpenAPI/YAML-Spezifikation) finden Sie im Abschnitt Ressourcen.