chemenu/kb/concepts/Green Suite Blind Spot.md

type, concept_type, tags, created, modified, related, sources, confidence, confidence_base, provenance, summary

type	concept_type	tags	created	modified	related	sources	confidence	confidence_base	provenance	summary
types/concept.md	problem	tests regression tooling quality	2026-08-31	2026-08-31	Command Round-Trip Integrity wikitool Denylist over Allowlist Ambient Environment Dependency Lint Workflow	Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31 Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31	0.70	0.70	sourced	Defekt, der eine vollstaendig gruene Testsuite ueberlebt, weil nie ein Test das richtige Verhalten behauptet hat - belegt an drei prio/1-2-Defekten (Round-Trip, Zitat-Notation-als-Code, Zitat-Limit)

Green Suite Blind Spot

Typ: Problem

Definition

Ein Green Suite Blind Spot ist ein Defekt, der eine vollständig grüne Testsuite überlebt, weil nie ein Test das richtige Verhalten behauptet hat. Die Suite ist nicht falsch und sie ist nicht kaputt - sie prüft nur, wovon sie weiß. Ein nie formuliertes Verhalten kann nicht fehlschlagen, also meldet ein grüner Lauf für diesen Bereich nichts, und die Grünfärbung wird als Aussage über den gesamten Code gelesen statt über den abgedeckten Ausschnitt.

Die Lücke wächst dort am schnellsten, wo zwei Komponenten sich erst in der Kombination widersprechen: jede für sich ist getestet, das Zusammenspiel hat nie jemand aufgeschrieben.

Kernpunkte

• Der Beleg aus diesem Stack (2026-08-31): zwei prio/1-Datenintegritätsdefekte lagen unter einer vollständig grünen Suite. 678 Tests waren grün, bevor die Zitat-Tests zu Gitea-Issue #17 geschrieben wurden; 67 Gate-Tests waren grün vor der Zählungsänderung desselben Tages. In keinem der beiden Fälle hatte je ein Test das falsche Verhalten festgehalten - genau deshalb hat es überlebt¹ .
• Die Zahl der grünen Tests sagt nichts über den ungetesteten Bereich. Sie misst, wie viel bekanntes Verhalten abgesichert ist. Ein Defekt in unbekanntem Verhalten ist von einer grünen 678er-Suite genauso wenig ausgeschlossen wie von einer grünen 60er-Suite¹ .
• Das ist etwas anderes als eine falsche Zusicherung. Ein Test, der das falsche Verhalten festschreibt, wird beim Fix rot und zwingt zur Entscheidung. Der blinde Fleck erzeugt gar keinen Widerstand: der Fix ändert Verhalten, das nie jemand behauptet hat, und die Suite bleibt grün - vorher wie nachher¹ .
• Gegenmittel 1 - den neuen Test rot beweisen, bevor man ihm glaubt. Bei der Reparatur von Issue #17 wurde nicht behauptet, der neue Test hätte den Defekt gefangen: die alte Implementierung wurde rekonstruiert und gegen ihn laufen gelassen (ALTER Code -> Beziehungen erhalten: False, NEUER Code -> Beziehungen erhalten: True)¹ .
• Gegenmittel 2 - den Umfang messen statt schätzen. Der Scan über den Korpus ergab 8 Seiten mit 74 Zeilen in der gefährdeten Position und hielt damit einen laufenden Ingest an, der cite add auf genau diese Seiten aufgerufen hätte. Eine Schätzung hätte diese Entscheidung nicht getragen¹ .
• Gegenmittel 3 - einen Bericht aus zweiter Hand nachstellen, nicht übernehmen. Die Meldungen eines Subagenten wurden am Code nachvollzogen, bevor etwas geändert wurde, und die Prüfung erweiterte den Umfang zweimal: um rename und den cite sync-Verlustpfad beim ersten Defekt, und um die Feststellung, dass xref remove das undeklarierte Feld gar nicht erreichen konnte, beim zweiten¹ .
• Ein dritter Beleg: lint maß Zeilenbreite statt Zitat-Anzahl, und niemand hatte je über die eigene Zitat-Syntax geschrieben. Gitea-Issue #20 stellte selbst fest: "auch dieser Fall war von keinem Test abgedeckt, weil bisher niemand eine Seite über die Zitat-Notation geschrieben hatte." Das Zitat-Limit (Issue #22) zählte parallel >-Zeilen statt Zitate - ein Defekt, den eine einzige Testseite mit einem umbrochenen Zitat sofort zeigt, aber den niemand geschrieben hatte, bis eine reale Seite genau das tat. Beide behoben in 1.7.2. Gegenmittel 1 griff erneut: acht neue Tests wurden gegen eine auf No-op zurückgesetzte Implementierung scharf geprüft und liefen rot, bevor der Fix als bewiesen galt.
• Eine Ablehnung, die auf ein anderes Kommando verweist, ist selbst ein blinder Fleck. Die Denylist aus 1.4.0 war richtig, ihr Verweisziel nicht: sie behauptete ungeprüft, xref add und xref remove deckten die Seiten-Referenz-Felder ab, was für eine Source-Seite falsch war. Die Regel dazu steht bei Denylist over Allowlist¹ .
• Der Befund stützt die Prämisse von Gitea-Issue #8 - dass eine grüne Suite kein Beleg für Vollständigkeit ist und ein Bereich seinen eigenen Nachweis braucht¹ .
• Issue #8 wurde am 2026-08-31 mit 1.7.1 geschlossen, und zwar über eine Isolierung der Testausführung statt über weitere Einzeltests² . Der dort behandelte Fall ist aber eine eigene Klasse und kein blinder Fleck: dort behauptete ein Test das richtige Verhalten und war grün, weil die Umgebung lieferte, was der Code hätte liefern müssen. Abgrenzung und Beleg bei Ambient Environment Dependency.
• Gegenmittel 1 hat sich dort erneut bewährt. Vor der Härtung war die Suite unter der gehärteten Umgebung bereits grün (695 Tests), der Schutz also durch keinen roten Lauf belegt. Erst die Gegenprobe - dieselbe Funktion antwortet ohne Isolierung mit dem globalen git-Namen des Entwicklers, mit Isolierung None - zeigte, dass er greift² .

Beispiele

• wikitool - Issue #17 (cite add löschte Inhalt hinter dem Fußnotenblock) und Issue #18 (Referenz-Arrays einer Source-Seite unerreichbar), beide unter grüner Suite entstanden und beide durch einen Ingest, nicht durch einen Testlauf, gefunden
• Command Round-Trip Integrity - die Defektklasse, die besonders anfällig ist, weil jeder beteiligte Aufruf für sich getestet und für sich korrekt ist
• Lint Workflow - Issue #20 ([^cite-id]/[[Wikilink]] in Backticks oder einem Fence zählte als echte Referenz) und Issue #22 (Zitat-Limit zählte >-Zeilen statt Zitate), beide gefunden bei einer Seite, die tatsächlich über die eigene Notation schrieb, nicht durch einen Testlauf

Wann zu verwenden

• Wenn eine grüne Suite als Argument für die Korrektheit einer Änderung angeführt wird: die Frage ist nicht, wie viele Tests grün sind, sondern welcher Test rot geworden wäre.
• Beim Schreiben eines Regressionstests: erst gegen den alten Code laufen lassen. Ein Test, der nie rot war, belegt nichts.
• Wenn ein Defekt im Betrieb auffällt statt im Testlauf: die Frage nach dem fehlenden Test gehört zur Ursachenanalyse, nicht zur Nacharbeit.

Wann NICHT zu verwenden

• Als Argument gegen Testabdeckung. Der Befund entwertet keinen einzigen der 678 grünen Tests; er bestreitet nur, dass ihre Zahl eine Aussage über das trifft, was niemand aufgeschrieben hat.
• Für Defekte, die ein Test sehr wohl abgedeckt hätte und die durch einen übersprungenen oder nicht ausgeführten Lauf durchgerutscht sind. Das ist ein Prozessfehler, kein blinder Fleck.

Verwandte Concepts

• Command Round-Trip Integrity
• Denylist over Allowlist
• Ambient Environment Dependency
• Structural Enforcement over Documented Rule

Beziehungen

• begünstigt: Command Round-Trip Integrity
• trat auf in: wikitool
• belegt an: Denylist over Allowlist
• abzugrenzen von: Ambient Environment Dependency
• belegt an: Lint Workflow

Siehe auch

• Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31
• Command Round-Trip Integrity
• wikitool
• Denylist over Allowlist
• Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31
• Ambient Environment Dependency
• Lint Workflow

Fußnoten

---

1. Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31 ↩︎

2. Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31 ↩︎