IT-Works/Wegwichtel
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

directory cleanup for tests
Sonarqube Scanner / Prepare environment (push) Successful in 11s
Details
Sonarqube Scanner / Build and test (push) Successful in 29s
Details
Sonarqube Scanner / SonarQube analysis (push) Successful in 1m25s
Details
Sonarqube Scanner / Deploy to Server (push) Successful in 7s
Details

Browse Source
This commit is contained in:
Florian Zumpe
2026-10-04 08:12:08 +02:00
parent 4e7b519275
commit 497b7b8050
6 changed files with 120 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+15 -1
View File
@@ -96,13 +96,27 @@ database/schema.sql SQLite-Schema
data/ lokale SQLite-Datei
storage/active/routes/ aktive GPX-, Bild- und Audiodateien
storage/trash/routes/ zum Löschen markierte Strecken
examples/ Beispiel-GPX
test/ automatisierte Tests
test-support/ isolierte Testhilfen und synthetische GPX-Testdaten
tools/python/ interaktive API-Werkzeuge ohne Node.js-Abhängigkeit
```
## Automatisierte Tests
GPX-Testdaten liegen in `test-support/gpx-fixtures.js`. Die API-Tests schreiben sie
bei Bedarf in ein temporäres Verzeichnis. Mitgelieferte Beispielstrecken oder
Dateien unter `examples/` werden nicht vorausgesetzt.
Das optionale Präsentations-Uploadskript verwendet ausdrücklich angegebene Dateien:
```bash
bash scripts/upload-presentation-route.sh https://wegwichtel.de/api /pfad/strecke.gpx /pfad/stationen.json
```
Die JSON-Datei enthält `name`, `description` und `pois` mit `title`, `description`,
`lat`, `lon`, `triggerRadiusM` und `sequence`. Die Skript-Tests erzeugen ihre Daten
selbst und simulieren die HTTP-Aufrufe, einschließlich des Aufräumens bei Fehlern.
Die REST-Integrationstests starten die Anwendung über `npm start` mit isolierten temporären Daten- und Speicherverzeichnissen. Der eigentliche Node.js-Prozess lauscht innerhalb des Testaufbaus auf `127.0.0.1:47146`. Davor läuft ein ausschließlich für die Tests bestimmter Reverse-Proxy auf `http://127.0.0.1:47145`, sodass dieser Loopback-Endpunkt das einzige Ziel der API-Aufrufe bleibt. Der Produktivserver wird von der Testsuite nicht angesprochen.
Der lokale Proxy lässt `GET`, `HEAD` und `OPTIONS` ohne Anmeldung passieren. Für `POST`, `PUT`, `PATCH` und `DELETE` antwortet er zunächst mit `401 Unauthorized` und `WWW-Authenticate: Basic`, sofern kein gültiger Authorization-Header vorhanden ist. Nach erfolgreicher Basic-Auth-Prüfung entfernt der Proxy den Header wieder und leitet den Request an den lokal per NPM gestarteten Server weiter. Damit wird ein möglicher Nginx-Passwortschutz für schreibende Operationen realistisch simuliert, ohne Authentifizierung in die Anwendung selbst einzubauen.