List view
Epic Als Entwicklungsteam möchte ich automatisierte API-Tests für alle Endpunkte von zmsapi und zmscitizenapi mit REST Assured implementieren, damit die kontinuierliche Qualitätssicherung und Regressionstests für unsere 327 API-Endpunkte gewährleistet sind und manuelle Testaufwände reduziert werden. Als Entwicklungsteam: Für das gesamte Entwicklungsteam, das die Qualität und Stabilität der API-Services sicherstellen muss. Damit: Alle 327 API-Endpunkte (166 in zmsapi, 161 in zmscitizenapi) werden kontinuierlich und automatisiert getestet. Dies löst das Problem manueller API-Tests, reduziert das Risiko von Produktionsfehlern und ermöglicht eine schnellere und sicherere Entwicklung durch frühzeitige Erkennung von Regressionen. Hintergrundinformationen I Informationen für die Umsetzung/Entwicklung Diese Epic umfasst die vollständige Implementierung von REST Assured API-Tests für das eAppointment-System. Das System verfügt über zwei Haupt-APIs: zmsapi: 166 Endpunkte für interne Verwaltungsfunktionen zmscitizenapi: 161 Endpunkte (39 Basis-Endpunkte × 4 Sprachen + 5 zusätzliche) Technische Architektur: REST Assured Framework für HTTP-API-Tests Java/Maven-basierte Teststruktur im api-tests/ Verzeichnis MySQL-Testdatenbank basierend auf .resources/zms.sql Schema Integration in GitHub Actions CI/CD Pipeline Unabhängige Testdaten ohne Kopplung an Unit-Tests Projektstruktur Bsp.: eappointment/ ├── api-tests/ # Neue Java/REST Assured Tests │ ├── pom.xml # Maven Konfiguration │ ├── src/test/java/ # Test-Implementierungen │ └── src/test/resources/ # Schema und Testdaten └── README.md # Dokumentation eappointment/ ├── api-tests/ # Neue Java/REST Assured Tests │ ├── pom.xml # Maven Konfiguration │ ├── src/test/java/ # Test-Implementierungen │ │ ├── zmsapi/StatusEndpointTest.java # Erster Test │ │ │ └── helpers/TestDataBuilder.java # Test-Daten Helper │ └── src/test/resources/ # Schema und Testdaten │ ├── db/01-base-schema.sql # Kopie von zms.sql │ │ └── db/02-status-test-data.sql # Minimale Testdaten └── README.md # Dokumentation Die Testdaten-Architektur folgt einem inkrementellen Migrationsansatz, der vollständig unabhängig von den Anwendungsmigrationen operiert: Basis-Schema: Ausgangspunkt ist eine saubere Kopie der .resources/zms.sql als leeres Basisschema ohne Testdaten. Inkrementelle Test-Migrationen: Für jeden neuen Testfall oder jede neue User Story wird eine separate Testdaten-Migration erstellt, die ausschließlich die für diesen spezifischen Test benötigten Daten hinzufügt. Vollständige Unabhängigkeit: Diese Test-Migrationen sind komplett entkoppelt von den normalen Anwendungsmigrationen. Sie dienen ausschließlich der Bereitstellung von Testdaten und nehmen keine Schema-Änderungen vor. Struktur-Beispiel: src/test/resources/db/ ├── 01-base-schema.sql # Basis: zms.sql ├── 02-status-endpoint-data.sql # Minimale Daten für /status ├── 03-appointment-crud-data.sql # Daten für Termin-Tests └── 04-user-auth-data.sql # Daten für Authentifizierung Akzeptanzkriterien Alle 327 API-Endpunkte haben automatisierte REST Assured Tests Tests laufen erfolgreich in der GitHub Actions Pipeline nur bei Pull Requests Testdatenbank mit .resources/zms.sql Schema ist konfiguriert Dokumentation für API-Test-Erweiterungen ist verfügbar in der README.md Test-Reporting und Fehlerbehandlung sind implementiert Berichte sind im Github-Actions Verlauf herunterladbar Die Berichte sind auf den Github-Pages https://it-at-m.github.io/eappointment/ einsehbar.
Overdue by 2 month(s)•Due by December 31, 2025mellon zmsadmin zmsapi zmscalldisplay zmsclient zmsdb zmsdldb zmsentities zmsmessaging zmsslim zmsstatistic zmsticketprinter
Overdue by 1 year(s)•Due by January 31, 2025•1/1 issues closed