---
# System prepended metadata

title: Automatisierte Funktionstests für OJS

---

# Automatisierte Funktionstests für OJS
## 2025-03-27
### Anwesende + Kurzvorstellung:

- Sebastian Schmidt (SLUB Dresden)--> Github: basti95
- Martin Brändle (UZH)
- Kristian Gavran (UZH)
- Ronald Steffen (FU Berlin)
- Joao Martins (USB Köln)
- Jon Richter (TIB Hannover, Berlin)
- Felix Henn (USB Köln)

### Ziele:

- Softwarequalität garantieren (Quality Assurance)
- OJS 3.3 > (3.4 >) 3.5 Migrationspfad in Bezug auf Plugins stabilisieren
- Betrieb sicherstellen
- Testprotokolle teilen
- User(-Accessibility) Testing (UAT)
- Development Experience steigern (DX, DevEx)

### Was soll getestet werden:

- OJS
- (OMP)

#### mit unterstützten Versionen

- 3.3
- 3.4
- 3.5

#### auf verschiedenen PHP Versionen

- 8.1
- 8.2

#### auf verschiedenen Plattformen

- Linux
- Windows
- macOS

#### jeweils Unit- und Integrations-Tests

- Kernsystem
    - Publikumsseite
    - _Administrationsseite_
- **Plugins**
    - Plugins in Plugin Galle\(r\)y, auch manchmal kaputt
    - GitHub et al.

#### Durchführung manueller Tests

- Checkliste zum Durchklicken
    - Funktion von Plugins
    - **Testprotokoll der UZH** **https://github.com/mpbraendle/OJS-Tests**
- Klassen von Regressionen
    - Übersetzungen
    - Fehler in Plugins können ganze Seiten/Instanzen lahmlegen
    - Plugininstallationen durch Journal Manager
        - Policy zum anschalten/abschalten implementieren

#### Ausführungsumgebungen automatisierter Tests

- lokale Entwicklung
    - übliche Testszenarien
- kontinuierliche Integration
    - https://forum.pkp.sfu.ca/t/austausch-zu-automatisierten-tests-fur-ojs/95072/4
        - Unit tests https://github.com/pkp/pkp-github-actions/blob/133c7a4e215df54a70d0fb3047cff8717f6f76f1/.github/actions/run-unit-tests.sh
        - Integrations tests https://github.com/pkp/pkp-github-actions/blob/133c7a4e215df54a70d0fb3047cff8717f6f76f1/.github/actions/run-data-integration-tests.sh
            - Verwendung: https://github.com/pkp/ojs/blob/235063a0fd01b22be339faa55286553799a5b632/.github/workflows/main.yml
- Laufzeittests:
    - niedrigschwellig
        - "Smoke Testing"
        - grobe Funktionsprüfung nach Änderungen
    - hochschwellig
        - Lasttests

### Technologien:

- Browserautomatisierung
- Infrastrukturautomatisierung
    - deklarativ
    - reproduzierbar
    - auch in CI
    - Cypress
    - DDEV Docker-basierte Entwicklungsumgebung https://ddev.com/ (aus Typo3 Ökosystem)
- quantitative Tests
    - K8s (+ GitLab) : Locust, K6
    - Apache httpd ab (https://httpd.apache.org/docs/2.4/programs/ab.html)
- CLI Testing: Hurl (CI) -> Anfragen und Ergebnisse definieren
    - https://hurl.dev/ / https://github.com/Orange-OpenSource/hurl
    - Alternativen:
        - https://httpie.io/cli / https://github.com/httpie/cli
        - https://github.com/ducaale/xh
        - https://github.com/rs/curlie
        - :sparkle: [Step CI — Open-source API-Testing Framework](https://stepci.com/), [stepci/stepci: Automated API Testing and Quality Assurance](https://github.com/stepci/stepci)
- Browsertesting: Cypress, Selenium, Playwright
    - für "Smoke-Tests"
    - Über CLI auslösbar (Headless)
- Observability-Integration und Alarmbenachrichtigungen als Reaktion auf frühere Ausfälle
    - Status Webseite
    - Nagios/Icinga (CheckMK)
        - Endpunkte prüfen mit Datenbankinhalten
        - DNS Einträge prüfen

### Umsetzung:

- Task Action Runner
    - https://just.systems/man/en/
    - https://mise.jdx.dev/
    - als "lokales CI" nicht mit händischem Bashskript, sondern DSL für Ausführung von Aufgaben
- containerisierte Ausführung der Tests
    - mit allen unveränderlichen Abhängigkeiten
    - deterministische Ausführbarkeit
- Routen für minimales Testen
    - /
    - Login
    - Plugin Liste in den Site Settings
    - Nutzer anlegen
    - Dokumente anlegen

### Nächster Termin:

- Themen:
    - Welche Smoke Tests brauchen wir (mindestens)?
    - Technologie durch Experimente festlegen
        - @jon Analogon zum Integrations Test mit Cypress aus der PKP GitHub Action lokal in Container ausführen

- Termin: 07.04. 14:00 --> https://conf.dfn.de/webapp/m/979178718
## 2025-04-07
### Anwesende:
- Sebastian Schmidt (SLUB Dresden)
- Martin Brändle (UZH)
- Kristian Gavran (UZH)
- Bernhard Schubert (UB Wien)
- Christian Buchmayer (UB Wien; OAO github: univie-oao-ojs)
- Joao Martins (USB Köln) (github: jpmmartins)
- Ronald Steffen (FU Berlin)
### Themen:
#### Welche Smoke Tests brauchen wir (mindestens)?
- @Martin reicht Liste erneut weiter
- @Bernhard hat ebenfalls Liste an Testfällen
- Ergänzung Uni Wien: https://github.com/univie-oao-ojs/OJS-Tests/blob/main/Walkthrough%20OJS%203.2.1.3%20(Stand%205.12.2022).pdf - Standardworkflow für Funktionstests
##### Testliste der UB Wien
###### Frontend
--------

    Ausgabe aufrufen
    Artikel Landing Page aufrufen
    Artikel PDF öffnen
    HTML: Artikel Landing Page mit HTML aufrufen
    HTML: Artikel mit HTML öffnen
    Zeichensätze testen: Inhaltsverzeichnis
    Zeichensätze testen: auf Artikelebene
    Hinzugefügte/enfernte Menüpunkte einer Zeitschrift ansehen

###### Backend
-------

    Login/Logout
    Login/Logout für Journal mit eigener Domain
    Einzelne Menüpunkte im Backend testen, insbesondere Einstellungen speichern (Einreichungen, Ausgaben etc.)
    Metadaten eines Beitrags ändern
    E-Mail Vorlagen prüfen
    Neuen Benutzer hinzufügen
    Begutachtungsformulare in Ordnung?
    Rubriken editieren und speichern
    XML Export testen
    Statistiken anzeigen
    Einen Upload mit QuickSubmit durchspielen
    Standard-Workflow bei unserer Testzeitschrift durchspielen (von der Submission bis zur Veröffentlichung)

###### Datenbank
---------

    Anzahl der Tabellen gegenüber Vorgängerversion
    Alle Tabellen UTF8?
    Dump-Größe (pre und post update)

###### Filesystem
---------

    Rechte wieder einschränken etc.
    

#### Technologie durch Experimente festlegen
- Hurl: Ronald hat getestet --> Gut für Abfragetests ob Seite erreichbar, fü r einen Teil der Tests gut nutzbar, kann DOM-Elemente finden aber kein Javascript ausführen
- Selenium/Playwright --> Für Tests zu DOM-Tree
- Autohotkey --> Keystroke-Basierte Tests
#### @jon Cypress + Github Action + Lokale Container
- Wegen Abwesenheit verschoben
### Nächster Termin:

- Hausaufgaben: Funktionslisten zusammenführen aus UB Wien und UZH
    - Kristian führt Listen zusammen in Repo von Martin (als CSV)
    - @alle: Liste prüfen nach Hinweis im Forum
- Themen:
    - Funktionsliste gemeinsam Diskutieren (festlegen 1. Scope)
- Termin: 5.5. 14:00-15:00 Uhr --> https://conf.dfn.de/webapp/m/979178718

## 2025-05-05
### Anwesende:
- Bernhard Schubert (UB Wien)
- Sebastian Schmidt (SLUB Dresden)
- Ronald Steffen (FU Berlin)
- Martin Brändle (UZH)
- Kristian Gavran (UZH)
- Joao Martins (USB Köln)
### Themen:
#### Funktionsliste Diskutieren
{%preview https://github.com/mpbraendle/OJS-Tests/blob/main/OJS-Automatic_testing-Test_cases.csv %}
- Unterscheidung zwischen Punkten, welche ohne weitere Informationen abprüfbar sind und Funktionen, zu denen zusätzliche Informationen vorhanden sein müssen
- Was ist mit Theme-Spezifischen Aspekten (bspw. Suche)?
- Welche Aspekte könnte man ohne zusätzliche Informationen abprüfen?
- Zentrale Konfigurationsdatei (.env) mit Umgebungsvariablen, welche für den Test genutz werden sollen
- Zeitersparnis v.a. dann gegeben, wenn Tests oft ausgeführt werden und nicht unregelmäßig
- Konzentration auf "low-hanging fruit" vs. komplexe, schwer zu automatisierende Tests die sich dann von Version zu Version ändern
- Zusätzlicher optionaler Test: Inline-HTML-Galley
- SSL-Zertifikats-Monitoring? -->

Priorisierung nach Schwierigkeitsgrad im .csv
--> Im ersten Schritt Prio 1 avisieren, Rest wenn 1 steht

### Nächster Termin:
Hausaufgaben:
- Aufgeteilt die Kriterien "Beschreibendes Prüfkriterium" -> Entsprechend auf der Spalte "Beteiligte" füllen
Themen: 
- Spalten "Beschreibendes Prüfkriterium" + "Technisches Prüfkriterium" gemeinsam diskutieren
Datum: 
19.05.2025 15:00 Uhr 
## 2025-05-19
### Anwesende:
- Sebastian Schmidt
- Bernhard Schubert
- Christian Buchmayer
- Kristian Gavran
- Ronald Steffen
- Joao Martins

### Themen:
#### Diskussion zu Beschreibenden + Technischen Prüfkriterien
- Link zu den Anforderungen: https://github.com/mpbraendle/OJS-Tests/blob/main/OJS-Automatic_testing-Test_cases.csv

## 2025-06-16
### Anwesende:
- Sebastian Schmidt
- Kristian Gavran
- Ronald Steffen
- Christian Buchmayer
- Joao Martins

### Themen:
#### Abstimmung zu Technologischer Implementierung

- Welche Tools könnten verwendet werden?
    - Python: Selenium + Playwright (https://playwright.dev/python/docs/intro)
        - Voraussetzungen:
            - Python 
            - Libraries
            - ggf. Treiberdateien
    - PKP: Cypress + Selenium Browser --> PHP-Code
        - Javascript-basiert, aber in anderen Sprachen verwendbar
    - Hurl (https://hurl.dev/): 
        - Für einfache Testcases gut, für Login-Test und komplexere Tests nicht geeignet
        - Installation einfach, Datei mit Testfällen einfach zu definieren
    - Lambda-Test.com (https://www.lambdatest.com)
        - Cloud-Plattformlösung
- Ansatz
    - Ggf. zwei verschiedene Lösungen implementieren?
        - Browserbasierter Ansatz + Hurl-Lösung parallel bereitstellen
            - Ronald hätte Interesse zu Hurl-Lösung beizutragen
            - Pro: Niedrigschwellig verwendbare Lösung + Featurereichere Lösung
    - Dokumentation erstellen: Beide Lösungen mit ihren Vorteilen erläutern + Supporten
    - Git-Repo mit Erläuterungen zu Konfiguration und Ausführung
    - ggf. Executables für Releases bereitstellen
    - Performance sollte auch beachtet werden
        - Multi-Journal-Installationen
    - Konfigurierbarkeit der Testt
        - "schnelle" Tests (z.B. nur FE)
        - "komplexere" Tests (FE + BE + Admin + ...) 
- ToDos:
    - Ronald Macht eine Demo mit Hurl fürs nächste Meeting mit unseren Prio1 Fällen und zeigt wie weit er kommt
    - Kristian testet Cypress-Ansatz als PoC fürs nächste Meeting
    - Sebastian macht equivalentes für Playwright
### Nächster Termin:
    - 07.07.2025 14:00
    
## 2025-07-07
### Anwesende:

- Sebastian Schmidt
- Kristian Gavran
- Ronald Steffen
- Christian Buchmayer
- Joao Martins

Themen:
### Vorstellung der Lösungsansätze mit Playwright, Cypress und Hurl
#### Hurl
- Konfigurationen ausgelagert in vars.env
- Demo, wie query_urls zwischengespeichert werden können

#### Cypress
- Heute noch nicht bereit

#### Playwright
- Herausforderung: mehrfaches Auftreten von Klassen
- 

#### Allgemeine Herausforderungen
- Welche Benutzer sollen für die Testausführung verwendet werden?
- Handhabung von Passwörtern: wie speichere ich diese auf eine sichere Art ab?
    - .env vs keypass-Integration?
    - .env als Pragmatischer Ansatz
    - .env in Gitignore

### Nächster Termin
- 25.08. 14:00

## 2025-08-25
### Anwesende:
- Sebastian Schmidt
- Ronald Steffen
- Martin Brändle
- Kristian Gavran
- Oliver Colberg (USB Köln)
- Joao Martins (USB Köln)

### Themen: 
#### Cypress Tests (von Kristian)
- Sind nun auch online im Repo
- Kristian präsentiert die Testfälle
    - Cypress öffnet eigenes Fenster
    - Zwischenschritte visuell dokumentiert, Elemente im HTML hervorgehoben
    - Umgebungsvariablen via JSON integriert
    - Abhängigkeiten: NPM/Node + Cypress (+ Browser)
    - Ausführen via ```npx cypress open```
    - Bei bestimmten Plugins existieren bereits Cypress-Tests

#### Auswertung Tests mit Playwright und Hurl
- Playwright:
    - Ronald hat getestet
    - In Installation zu nutzende Browser festlegen, sonst werden mehrere Heruntergeladen (trotzdem min. 1GB)
    - Nachvollziehbarkeit der Testergebnisse: https://playwright.dev/python/docs/trace-viewer mit in Doku integrieren
- Hurl:
    - primärer Anwendungsfall: Einfach strukturierte Tests
    - Auth + Forms funktionieren
    - Geringe Abhängigkeiten
    - Leichtgewichtig --> Schnellere Ausführzeiten

#### Weiteres Vorgehen
- Nutzungsanforderungen:
    - Git-Repository herunterladen können, Umgebungsvariablen-Dateien anpassen, Testsuit via Befehl ausführen
- Skript zur einfachen Ausführung (?)
- Agnostische Anforderungsliste prüfen, Implementierungsspezifische Beschreibung angeben
- Ergänzungen weiterer Testcases durch Community fördern!
    - Workflow um es in den verschiedenen Implementierungen abzubilden
- Testcases lokalisieren? -> @Kristian ergänzt lokalisierte Version für Englisch für Testcase-Liste

### Nächster Termin
06.10.2025 14:00
### TODOs:
- PR mit Playwright-Tests erstellen @Sebastian
- Lokalisieren der Testcases @Kristian
- Prüfen der Testfälle auf Abdeckung durch Testfälle durch @Ronald, @Sebastian, @Kristian
## 2025-10-06
### Anwesende:
- Sebastian Schmidt
- Ronald Steffen,
- Kristian Gavran
- Joao Martins
### Themen: 
#### Prüfen der Testfälle auf Abdeckung in Implementierung
@ Ronald
An 2025-10-06 neuer PR mit aktualisierten HURL-Testfällen + Doku --> @Kristian integriert diese

@Kristian
Erstellt noch Readme für Cypress Testfälle

***@Sebastian***
**Testfall 2 Current Issue: Abweichung:** Article URL wird nicht in Test geprüft sondern seperat geholt wenn ausgeführte Tests diese benötigen
**Testfall 4: Display Journal Archive:**
URL IN Technischer Doku abweichend?
**Testfall 14:** Prüfen der Suche über URL .../search statt via BASE_URL => Ronald testet auch in HURL diese Unterseite
**Testfall 20:** Abweichung in Wartezeit --> "Network Idle" vs. 3 Sekunden
**Testfall 21:** Aktuell prüft Test anderes Element, muss angepasst werden
**Testfall 24:** Plugin Aktivieren/Deaktivieren, aktuell nicht implementiert --> Equivalent bei Ronald: Auskommentiert, kann von erfahrenen Nutzern einkommentiert werden
---> Vorschlag: Konfigoption / Testsets mit "Invasiven Tests"
---> Alternativ: Prio auf 2
==> **Testfall 24 wird auf Prio 2 verschoben!**
**Testfall 26:** Aktuell prüft Test anderes Element, muss angepasst werden
**Testfall 27:** Aktuell prüft Test anderes Element, muss angepasst werden
**Testfall 29:** Nicht implementiert, benötige dafür Testinstanz mit anderen Settings
#### Weitere Implementierungsfragen
- Tests im Backend -> alles Via Admin oder Admin/"Regulärer"-User?
    - Cypress kann bereits nach Nutzerrollen unterscheiden, ist damit uneinheitlich zu Tests nur mit Admin-Rollen
    - Hurl Kann mehrere Nutzer nur mit verschiedenen Umgebungsvariablen abbilden
- .env-Beispiel-Dateien ergänzen?
    - Je nach Implementierung schon vorhanden
    - .env in Gitignore aufnehmen
- Umgebungsvariablen bitte einheitlich GROß schreiben
- Wie ist Zertifikatsprüfung geregelt?
    - In den Readme-Files ergänzen?
    - ggf. verfügbare CLI-Optionen im Readme verweisen
    - Default->Ungültige Zertifikate sollen Fehler werfen 


#### Kommunikation um Testsets nach außen
-> Verschoben
### Nächster Termin
17.11.2025 14:00 Uhr
--> Besprechen der Kreuztests + Kommunikationsplanung der Ergebnisse

### TODOs:
- Anpassungen der jeweiligen Testcases
- Zertifikatshandling im Readme ergänzen
- Kreuztesten der Implementierungen

## 2025-11-17
### Anwesende:
- Sebastian Schmidt
- Ronald Steffen
### Themen: 
#### Prüfen der Testfälle auf Abdeckung in Implementierung
@Kristian
Erstellt noch Readme für Cypress Testfälle
#### Ergebnisse Kreuztests
- Herausforderungen in Ausführung der Cypress Testfälle
    - Einrichtung bei Sebastian fehlgeschlagen
#### Kommunikation um Testsets nach außen

### Nächster Termin
- Zuerst Cypress-Readme + Tests notwendig

### TODOs:
@Kristian
- Readme erstellen und Benachrichtigen im Forum
@Alle: 
- Cypress-Implementierung testen sobald Readme existiert
### Abwesend
- João Martins (aufgrund eines anderen Termins)