44 lines
1.8 KiB
Markdown
44 lines
1.8 KiB
Markdown
# ADR 0003: Standardisierte Teststrategie
|
|
|
|
## Kontext
|
|
|
|
Die Module besitzen PHPUnit-Tests, ihre Prüfungen in einer echten
|
|
IP-Symcon-Installation waren jedoch unterschiedlich aufgebaut. Dadurch fehlten
|
|
ein einheitlicher Aufruf, sicherer Cleanup, maschinenlesbare Berichte und eine
|
|
verbindliche Regel für neue Module.
|
|
|
|
## Entscheidung
|
|
|
|
Enelix verwendet zwei Testebenen. PHPUnit bleibt die schnelle Pflichtprüfung bei
|
|
jedem Push. Zusätzlich erhält jedes Modul einen registrierten Symcon-Modultest
|
|
mit dem gemeinsamen `TestContext`. Der Runner unterstützt `single`,
|
|
`affected` und `all`, isoliert jeden Testlauf und liefert Konsole, JSON und
|
|
JUnit XML.
|
|
|
|
Der Manager-Test erzeugt jeden implementierten Verbrauchertyp und prüft ihn
|
|
einzeln sowie in einer gemeinsamen Konstellation. Neue Verbrauchertypen müssen
|
|
diese Matrix erweitern.
|
|
|
|
## Alternativen
|
|
|
|
- Nur PHPUnit: verworfen, weil das reale Objektmodell, Actions und
|
|
Modulinteraktionen nicht abgedeckt werden.
|
|
- Freie Schnellausführungs-Skripte pro Modul: verworfen, weil Aufbau, Cleanup
|
|
und Berichte erneut auseinanderlaufen würden.
|
|
- Ein drittes Test-Repository: vorerst verworfen, weil Tests zusammen mit dem
|
|
jeweiligen Modul versioniert und atomar geändert werden sollen.
|
|
|
|
## Folgen
|
|
|
|
Jedes neue Modul benötigt zusätzlich zu Unit-Tests einen Manifest-Eintrag und
|
|
einen Symcon-Test. Der Vertrags-Unit-Test verhindert unregistrierte Module.
|
|
Integrationstests benötigen einen isolierten IP-Symcon-8.x-Runner. Testobjekte
|
|
dürfen ausschließlich innerhalb der vom Framework erzeugten Kategorie liegen.
|
|
|
|
## Offene Punkte
|
|
|
|
- Bereitstellung und Registrierung des Gitea-Runners mit Label `symcon-8`.
|
|
- Festlegung der Aufbewahrungsdauer für JSON- und JUnit-Artefakte.
|
|
- Erweiterung der Manager-Matrix, sobald weitere Verbrauchertypen umgesetzt
|
|
werden.
|