Teststrategie

Ziel

Die Teststrategie stellt sicher, dass

alle definierten Features (z.B. Dokument speichern, Rechteverwaltung, Kollaboration) technisch korrekt umgesetzt sind und sich so verhalten, wie sie beschrieben sind.
die Tests das gewünschte Verhalten der Software dokumentieren.
sowohl die Abgrenzung und der Testumfang klar definiert sind.

Dieses Dokument bezieht sich ausschließlich auf Tests im Backend.

Ziel: Sicherstellen, dass einzelne Module oder Funktionen isoliert korrekt funktionieren.
Umfang:
- Validierung von Eingaben und Ausgaben.
- Fehlerbehandlung (z. B. ungültige Eingaben, Ausnahmen).
- Datenbankoperationen.
Beispiele:
- Token-Validierung für die Authentifizierung.
- CRUD-Operationen für Dokumente.

Ziel: Sicherstellen, dass verschiedene Backend-Komponenten korrekt zusammenarbeiten.
Umfang:
- Interaktion zwischen Datenbank und API-Endpunkten.
- Echtzeit-Kollaborationslogik.
Beispiele:
- Speichern und Abrufen von Dokumenten aus der Datenbank.
- Synchronisation von Änderungen in Echtzeit.

Tests sollten genau eine Funktionalität oder ein Verhalten prüfen.
Es ist zu vermeiden, mehrere Funktionalitäten in einem Test zu kombinieren.
Präzise und beschreibende Testnamen sind zu verwenden, um den Zweck des Tests klar zu machen.

Mocking-Frameworks (z. B. Mockito) sind zu verwenden, um Abhängigkeiten zu isolieren.
Gemeinsame Zustände zwischen Tests sind durch das Zurücksetzen der Testumgebung vor jedem Test zu vermeiden.

Feste Eingabedaten und deterministische Logik sind in den Tests zu verwenden.
Abhängigkeiten von externen Faktoren wie Systemzeit oder Netzwerkbedingungen sind zu vermeiden.
Konsistente Testumgebungen (z. B. identische Datenbankschemata und Konfigurationen) sind sicherzustellen.

Klare und beschreibende Testnamen (z. B. getByIdShouldReturnNotFoundForInvalidDocumentID) sind zu verwenden.
Eine konsistente Struktur, wie Arrange-Act-Assert (AAA), ist in den Testfällen einzuhalten.
Kommentare sind nur hinzuzufügen, wenn sie notwendig sind, um komplexe Logik zu erklären.

Der, in diesem Dokument, beschriebene Testumfang ist abzudecken.
Alle Randfälle und Szenarien, welche im Laufe der Entwicklung bekannt werden, werden durch Tests abgedeckt.

Validierung des Speicherns von Dokumenten.
Validierung des Abrufs von Dokumenten.
Validierung des Löschens von Dokumenten.
Fehlerbehandlung bei ungültigen Dokumentformat in der Datenbank.
Testen, dass ein Fehler zurückgegeben wird, wenn die Datenbank nicht verfügbar ist.

Validierung der Synchronisationslogik für Änderungen.
Sicherstellen, dass mehrere Nutzer gleichzeitig dasselbe Dokument bearbeiten können.

Validierung der Token-Generierung.
Validierung des Erstellens von geteilten Links.
Validierung des Widerrufs (Löschen) von geteilten Links.
Validierung des Abrufs von geteilten Links.
Validierung des Aktualisieren von geteilten Links.
Validierung, dass Berechtigungsstufen (z. B. Nur-Lesen, Bearbeiten) korrekt umgesetzt sind.
Validierung, dass abgelaufene Tokens keinen Zugriff mehr gewähren.
Sicherstellen, dass ein Benutzer ohne Berechtigung keinen Zugriff auf geteilte Inhalte erhält.

Validierung des Erstellen eines Exports
Validierung, dass exportierte Dateien den korrekten Inhalt und das richtige Format enthalten.
Validierung, dass Medien korrekt in exportierten Dateien eingebettet werden.
Validierung, dass nur Exports in die unterstützten Formate möglich sind.

Validierung der Erstellung von Versionen.
Validierung des Abrufs von Versionen.
Sicherstellen, dass das Wiederherstellen früherer Versionen korrekt funktioniert.
Sicherstellen, dass die Versionierung nachvollziehbar und chronologisch korrekt ist.
Validierung, dass Änderungen zwischen Versionen korrekt protokolliert werden.

Tests für Frontend-spezifische Features (z. B. UI/UX, clientseitige Validierung) sind nicht Teil dieser Teststrategie.