raw/notes/Conversation Transcript - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31.md
en
2026-08-31
tests
ci
tooling
quality
wikitool
Chemenu
Gitea Actions
AGENTS.md
Green Suite Blind Spot
Ambient Environment Dependency
Structural Enforcement over Documented Rule
Sitzung, die die Testsuite gegen stille Umgebungsabhaengigkeiten haertet (1.7.1, Issue #8): autouse-Fixture statt zweitem CI-Job, 702 Tests in vier Umgebungen, plus der Befund, dass checkout@v7 den CI-Container selbst konfiguriert
Source: Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31
Autor: Torben Datum: 2026-08-31 Raw-Dateien: raw/notes/Conversation Transcript - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31.md Typ: Notes
Zusammenfassung
Die Sitzung setzt Gitea-Issue #8 um und liefert 1.7.1 (31c9b81, Tag v1.7.1): eine
autouse-pytest-Fixture, die jeden Test von der Maschine trennt, auf der er läuft. Der Anlass lag
Wochen zurück - der erste CI-Lauf, der überhaupt bis pytest kam (Run 52), warf zwei Tests um,
die auf jeder Entwicklermaschine monatelang grün waren, weil config.default_author() per
git config user.name die globale git-Konfiguration desjenigen las, der die Suite startete.
Die Quelle ist vor allem deshalb interessant, weil die Messung vor der Änderung ein anderes Bild
ergab als erwartet: die Suite war unter der gehärteten Umgebung bereits grün (695 Tests). Die
vier bekannten Fälle waren in 1.0.1 und 1.2.0 einzeln repariert, ein fünfter existierte in
diesem Moment nicht. Damit war die Änderung keine Reparatur, sondern ein Schutz - und ein Schutz,
dessen Wirkung getrennt nachgewiesen werden muss, weil "alles bleibt grün" über ihn nichts
aussagt. Die Sitzung führt diesen Nachweis explizit: ohne Fixture liefert default_author() in
einem Nicht-Repository den globalen git-Namen des Entwicklers, mit Fixture None.
Zwei Befunde gehen über den Issue-Text hinaus. Erstens deckt die Fixture auch git-eigene
Identitäts- und Ortsvariablen ab, die der Vorschlag nicht nannte. Zweitens - und für die
Bewertung der verworfenen Alternative entscheidend - zeigt das CI-Log von Run 79, dass
actions/checkout@v7 inzwischen selbst eine globale git-Konfiguration im Job-Container anlegt.
Der Container ist damit nicht mehr die konfigurationsfreie Maschine, als die Run 52 ihn
vorgefunden hatte.
Kernaussagen
Der Auslöser und seine Wiederholung. Run 52 (2026-08-30) meldete 2 failed, 628 passed mit
AssertionError: ERROR No author configured for this instance. Beide Tests wurden in 1.0.1
repariert. In 1.2.0 führten zwei neue Tests dieselbe Abhängigkeit erneut ein, geschrieben
von jemandem, der das Issue vorher gelesen hatte. Der Issue-Kommentar zieht daraus den Schluss,
der die Sitzung steuert: "die Suite lädt neue Fälle schneller ein, als jemand sie findet."
Zwei Optionen, eine seit dem Kommentar entschieden. Autouse-Fixture in conftest.py gegen
einen zweiten, gehärteten pytest-Schritt in CI. Der CI-Schritt meldet erst nach dem Push und
schützt den Lauf des Entwicklers nie - also genau dort nicht, wo die Fälle entstehen.
Die Messung vor der Änderung ergab 695 grüne Tests unter der gehärteten Umgebung. Kein
fünfter Fall war offen. Das verschiebt die Änderung von Reparatur zu Schutz und macht einen
eigenen Wirksamkeitsnachweis nötig.
Der Wirksamkeitsnachweis. In der Sitzung ausgeführt: default_author() with the ambient environment: 'Torben Nehmer'. Unter der Fixture antwortet dieselbe Funktion None. Der neue
Test wäre vorher rot gewesen und ist nachher grün - was die Ausgangsmessung nicht zeigen
konnte.
Über den Vorschlag hinaus abgedeckt:GIT_DIR, GIT_WORK_TREE, GIT_AUTHOR_NAME,
GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, EMAIL. Begründung im Code:
GIT_AUTHOR_NAME sticht git config user.name und ist damit derselbe Fehler durch eine andere
Tür; ein verirrtes GIT_DIR würde jedes Fixture-Repo auf den Checkout des Entwicklers zeigen
lassen.
WIKI_TRACE_DIR bleibt als einzige Variable gesetzt. Tracing wird nie suite-weit
abgeschaltet, weil zwei Telemetrie-Tests behaupten, dass ein Trace geschrieben wird.
isolated_trace_dir nimmt hermetic_environment jetzt als Parameter - nicht für einen Wert,
sondern damit die Reihenfolge der beiden autouse-Fixturen ausgesprochen ist statt aus der
Deklarationsreihenfolge zu folgen.
Bewusst kein WIKI_AUTHOR in der Fixture-Basis. Der billigere Weg wäre der falsche
gewesen: ein gemeinsamer Default macht den None-Zweig von default_author() untestbar, weil
dieser Zweig nur auf einer Maschine existiert, die niemanden kennt. Die Suite sähe grüner aus
und bewiese weniger.
Ein Test, der direkt patcht, bleibt.test_new_source_fails_hard_without_any_author patcht
default_author weiterhin, obwohl die Umgebung jetzt ohnehin None liefern würde. Der Patch
pinnt den Wert unabhängig von der Umgebung und hält den Test damit bei der Fehlerbehandlung der
CLI statt bei der Umgebung.
Vier Umgebungen, ein Ergebnis: 702 Tests grün. Entwickler-Shell; absichtlich vergiftet
(WIKI_AUTHOR, WIKI_TRACE=0, WIKITOOL_* und GIT_* auf Müll); env -i mit leerem HOME
und ohne git-Konfiguration; CI-Container (702 passed in 15.84s). Der vergiftete Lauf war im
Issue nicht verlangt und prüft die Gegenrichtung: nicht "übersteht die Suite, nichts zu haben",
sondern "übersteht sie, das Falsche zu haben".
Die Fixture wird selbst getestet.test_hermetic_env.py behauptet die geleerten Variablen,
das leere HOME, dass git config user.name nichts antwortet, und alle drei Zweige von
default_author(). Begründung: eine Fixture, gegen die nichts assertet, kann eine Variable
verlieren, ohne dass ein Lauf rot wird - dasselbe Versagen eine Ebene höher.
actions/checkout@v7 legt selbst eine globale git-Konfiguration an. Aus dem Log von Run 79:
Copying '/root/.gitconfig' to '/tmp/b93ea7a3-.../.gitconfig' und Temporarily overriding HOME='/tmp/b93ea7a3-...' before making global git config changes; der Tool-Environment-Schritt
schreibt zusätzlich safe.directory global. Der Job-Container hatte die Eigenschaft
"keine globale Konfiguration" in Run 52 also zufällig. Ein Guard, der darauf baut, hätte
irgendwann still aufgehört zu greifen.
CI bleibt bei einem Testlauf. Der Kommentar am Tests-Schritt in .gitea/workflows/ci.yml
hält fest, warum der zweite Lauf nicht nachgerüstet wird.
Der dist export-Schritt meldete 11 Instructions und 5 Skills gegen 14 und 6 im Dev-Baum -
Beleg, dass instructions/dev/testing-conventions.md die Distribution nicht erreicht.
Aufgaben
Issue #8 umgesetzt, verifiziert und geschlossen (1.7.1, 31c9b81, Tag v1.7.1)
Gitea-Issue #22 (prio/3, size/XS): lint zählt Zitat-Zeilen statt Zitat-Blöcke
(lint.py:157), ein umbrochenes Zitat wird als vier gemeldet
Gitea-Issue #23 (prio/2, size/S): nichts erzwingt, dass eine neue Tool-Variable in
_WIKITOOL_ENV landet - die Regel steht in testing-conventions.md, aber genau eine
Prosa-Regel war die Prämisse von #8
Nicht übernommen
Die konkrete Liste der geleerten Variablen als Wiki-Inhalt. Sie steht in conftest.py und
in instructions/dev/testing-conventions.md; eine dritte Kopie im kb/ wäre die, die driftet
(AGENTS.md-Invariante 8). Die Kernaussagen nennen nur die Kategorien und die Begründung.
Die Publish- und Verifikationsmechanik (publish ohne --message endet mit Exit 2,
git ls-remote als Gegenprobe). Das ist in publish-cycle.md und SOUL.md geregelt, nicht
Erkenntnis dieser Sitzung.
Die vollständigen Issue-Texte von #22 und #23. Der Tracker hat Zustand und Verlauf, das
Wiki nicht; hier steht nur, dass und warum sie existieren.
Der git init -q -b main-Hinweis zur init.defaultBranch-Advisory. Werkzeugdetail ohne
eigenen Erkenntniswert, steht in der Instruction.