讨论： Die Testpyramide: welcher Test auf welche Ebene gehört

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

暂无译文，显示原文。 原文

«Ende-zu-Ende … auf dem Integrationszweig statt bei jedem Commit» verschiebt den Fehlschlag an den teuersten Ort. Läuft die Ende-zu-Ende-Suite erst nach dem Merge, wird ein gebrochener Kaufablauf entdeckt, wenn die Autorin schon an etwas anderem arbeitet, der Zweig mehrere fremde Änderungen enthält und die Suche mit `git bisect` über gemergte Commits beginnt; genau die Diagnoseschwäche, die der Artikel den breiten Tests zuschreibt, wird so vergrössert. Die Alternative ist nicht «bei jedem Push», sondern «vor dem Merge auf dem gemergten Stand»: Merge-Queues (GitHub) und Merge-Trains (GitLab) bauen den Zweig auf den aktuellen Hauptzweig und führen die langsame Suite genau einmal pro Merge-Kandidat aus, ohne die schnelle Rückmeldung pro Push zu verzögern. Dann bleibt der Hauptzweig grün, und der Fehlschlag trifft die Person, die ihn beheben kann, mit einem Diff von einer Änderung. Für Teams ohne Merge-Queue ist die Regel «Ende-zu-Ende vor dem Merge, angestossen von Hand oder per Label» immer noch besser als «nach dem Merge».

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

暂无译文，显示原文。 原文

Zwei Ergänzungen, die die Ebenen prüfbar machen. Das Buch «Software Engineering at Google» ersetzt die unscharfen Begriffe Unit, Integration und Ende-zu-Ende durch Testgrössen mit harten Kriterien: «small» läuft in einem Prozess ohne Netz, Platte und Schlaf, «medium» auf einer Maschine mit localhost-Netz, «large» darf alles; die Grösse wird pro Test deklariert und von der Testinfrastruktur erzwungen, was die im Artikel genannten «als Unit-Tests getarnten Integrationstests» beim Ausführen statt beim Lesen entlarvt. Fowler unterscheidet zudem «solitary» und «sociable» Unit-Tests: Ein sociable Unit-Test ruft die echten Nachbarklassen auf und ersetzt nur, was langsam oder nichtdeterministisch ist – die Antwort auf den ersten Stolperstein, dass Tests mit lauter Attrappen die Attrappen prüfen. Als Gegenmodell kursiert die «Testing Trophy» (Kent C. Dodds), die die Integrationsebene zur breitesten macht; für Frontends mit viel Verdrahtung und wenig eigener Logik ist das oft die ehrlichere Form, und sie widerspricht der Pyramide nicht in der Sache, weil beide nach Laufzeit und Diagnosewert argumentieren.