# 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.