Ein Monorepo (monolithisches Repository) ist eine Code-Verwaltungsarchitektur, bei der mehrere Projekte, Anwendungen und gemeinsam genutzte Bibliotheken in einem einzigen Git-Repository koexistieren, verwaltet durch Orchestrierungs-Tools wie Nx, Turborepo oder Lerna, die Builds und Tests basierend auf dem Abhängigkeitsgraphen optimieren.
Monorepos haben gewonnen. Frontend-Teams, die mehrere Anwendungen verwalten — eine Marketing-Website, ein Admin-Dashboard, eine Kunden-App, ein Partner-Portal — bündeln sie in einem einzigen Repository. Das ist einfacher für Code-Sharing, konsistenter für das Design System, effizienter für übergreifende Aktualisierungen.
Aber für visuelles Testen ist es ein logistischer Albtraum. Nicht weil visuelles Testen im Monorepo nicht funktioniert. Es funktioniert sehr gut. Das Problem ist, dass es zu gut funktioniert: Eine Änderung in einem Shared Package löst potenziell visuelle Tests auf allen Projekten aus, die davon abhängen. Und wenn Ihr Monorepo 15, 30 oder 50 Projekte enthält, ist "alles bei jedem Commit testen" keine Option mehr.
Das Grundproblem: Der Abhängigkeitsgraph
In einem Monorepo sind Projekte nicht unabhängig. Sie teilen Packages: ein Design System, eine Utility-Bibliothek, gemeinsame Komponenten, geteilte Konfigurationen. Diese Abhängigkeiten bilden einen Graphen — und dieser Graph macht visuelles Testen komplex.
Nehmen wir ein konkretes Beispiel. Sie haben ein Package "ui-components", das Ihre Buttons, Formulare und Navigationskomponenten enthält. Dieses Package wird von 12 Anwendungen in Ihrem Monorepo verwendet. Sie ändern das Padding eines Buttons in "ui-components". Visuell betrifft diese Änderung potenziell alle 12 Anwendungen. Jede Seite, die einen Button enthält, könnte ein anderes Rendering haben.
Wenn Sie visuelle Tests auf allen 12 Anwendungen starten, erfassen Sie potenziell Hunderte von Screenshots. Die CI/CD-Pipeline dauert 45 Minuten. Entwickler warten. Und wenn einer der Tests fehlschlägt — ein False Positive aufgrund eines Headless-Rendering-Problems — muss der Entwickler des "ui-components"-Packages einen Fehler in einer Anwendung untersuchen, die er nicht einmal kennt.
Das ist unhaltbar. Und genau das passiert in Monorepos ohne visuelle Teststrategie.
Nur testen, was sich geändert hat: Das Betroffenheitsprinzip
Die erste Regel des visuellen Testens im Monorepo ist in der Theorie einfach, in der Praxis komplex: Nur testen, was von der Änderung betroffen ist.
Moderne Monorepo-Tools — Nx und Turborepo an der Spitze — können den Abhängigkeitsgraphen berechnen und die "betroffenen" Projekte einer Änderung identifizieren. Wenn Sie eine Datei im Package "ui-components" ändern, kann Nx Ihnen sagen, dass die Anwendungen A, C, F und K von diesem Package abhängen, aber nicht B, D und die anderen.
Das ist die Basis. Aber für visuelles Testen reicht das nicht aus. Denn "Anwendung A hängt von ui-components ab" bedeutet nicht, dass alle Seiten von Anwendung A die geänderte Komponente verwenden. Wenn Sie den Button geändert haben, sind nur die Seiten betroffen, die einen Button enthalten. Seiten ohne Button sind stabil.
Intelligentes visuelles Testen im Monorepo arbeitet daher auf zwei Filterebenen. Erste Ebene: Welche Projekte sind von der Änderung betroffen, laut Abhängigkeitsgraph. Zweite Ebene: Welche Seiten oder Komponenten dieser Projekte verwenden tatsächlich das geänderte Element.
Die erste Ebene wird von den Monorepo-Tools gelöst. Die zweite Ebene ist viel schwieriger — sie erfordert entweder eine statische Code-Analyse (welche Seiten importieren welche Komponente) oder ein explizites Mapping, das vom Team gepflegt wird (diese Komponente wird auf diesen Seiten verwendet).
Die Realität der Shared Packages
Shared Packages sind die Stärke und die Schwäche des Monorepos. Sie ermöglichen Konsistenz: ein einziges Design System, eine einzige Wahrheitsquelle für visuelle Komponenten. Aber sie erzeugen auch einen erheblichen Blast Radius.
Es gibt drei Arten von Shared Packages, die spezifische Probleme für visuelles Testen verursachen.
UI-Komponenten-Packages. Das ist der offensichtlichste Fall. Eine Änderung an einem Button, Formular oder Modal betrifft visuell alle Seiten, die sie verwenden. Der Blast Radius ist proportional zur Popularität der Komponente. Eine Layout-Komponente, die überall verwendet wird (Header, Footer, Sidebar), hat maximalen Blast Radius.
Style- und Token-Packages. Eine Änderung an Design Tokens — Farben, Abstände, Typografie — ist im traditionellen Abhängigkeitsgraphen oft unsichtbar. Wenn Sie die Primärfarbe in Ihrer Token-Datei ändern, sieht der Abhängigkeitsgraph eine Änderung im Package "design-tokens". Aber diese Änderung betrifft visuell alles: jeden primären Button, jeden Link, jedes akzentuierte Element in allen Anwendungen. Der Blast Radius ist total.
Utility-Packages mit visuellen Seiteneffekten. Weniger offensichtlich: Utility-Funktionen, die Daten formatieren, Text kürzen oder Layouts berechnen. Eine Änderung an einer Textkürzungsfunktion — von 100 auf 80 Zeichen Maximum — hat einen direkten visuellen Einfluss auf alle Komponenten, die sie verwenden. Aber der Abhängigkeitsgraph weiß nicht, dass es eine "visuelle" Änderung ist.
Strategien, die funktionieren
Nachdem wir Dutzende von Teams beim Umgang mit visuellem Testen im Monorepo beobachtet haben, hier die Strategien mit den besten Ergebnissen.
Strategie 1: Visuelles Testen in Schichten
Organisieren Sie Ihre visuellen Tests in drei Schichten mit unterschiedlichen Ausführungsfrequenzen.
Die Komponenten-Schicht. Testen Sie jede Design-System-Komponente isoliert, über Storybook oder Äquivalent. Diese Tests werden nur ausgeführt, wenn sich das Komponenten-Package ändert. Sie sind schnell (einige Minuten) und schützen die Bibliothek selbst. Das ist das erste Netz, wie im Artikel über visuelle Tests in Design Systems beschrieben.
Die Seiten-Schicht — betroffen. Testen Sie die Seiten der von der Änderung betroffenen Anwendungen, identifiziert durch den Abhängigkeitsgraphen. Diese Tests laufen bei jedem Pull Request, aber nur auf den betroffenen Projekten. Sie sind das Herzstück Ihrer Strategie.
Die vollständige Schicht. Testen Sie alle Seiten aller Anwendungen. Diese Schicht wird nicht bei jeder PR ausgeführt — das ist zu teuer. Führen Sie sie einmal täglich (nightly) oder vor jedem Release aus. Wie in unserem Leitfaden zur visuellen Überwachung in der Produktion beschrieben, fängt diese Schicht Regressionen ab, die der Abhängigkeitsgraph nicht vorhersagen konnte.
Strategie 2: Explizites Komponente-Seite-Mapping
Pflegen Sie eine Konfigurationsdatei, die jede Shared-Komponente den Seiten zuordnet, die sie verwenden. Wenn sich die Button-Komponente ändert, zeigt die Datei an, dass die Seiten /login, /signup, /checkout und /settings von Anwendung A diese Komponente verwenden. Nur diese Seiten werden getestet.
Dieses Mapping manuell zu pflegen ist mühsam. Aber es kann automatisch durch statische Code-Analyse generiert werden — durch Durchlaufen der Imports jeder Seite und Zurückverfolgen der Abhängigkeiten. Nx bietet Plugins an, die diese Art von Analyse erleichtern.
Der Vorteil ist beträchtlich: Statt 200 Seiten von Anwendung A zu testen, wenn sich eine Komponente ändert, testen Sie nur 12. Die Pipeline geht von 30 Minuten auf 3 Minuten.
Strategie 3: Geteilte Baseline mit Override
In einem Monorepo mit gemeinsamem Design System haben visuelle Baselines (die Referenz-Screenshots) eine Besonderheit: Shared-Komponenten haben dasselbe Rendering in allen Anwendungen (theoretisch). Sie können daher eine Design-System-Baseline auf Package-Ebene pflegen und Baselines auf Anwendungsebene nur dann neu erfassen, wenn sich der Integrationskontext ändert.
Konkret: Wenn Sie die Button-Komponente ändern, aktualisieren Sie die Button-Baseline im ui-components-Package. Anwendungen, die den Button verwenden, erben diese neue Baseline. Nur Anwendungen, in denen der Button im Kontext ein anderes Rendering hat (wegen spezifischem CSS, Theme oder Override), brauchen eigene Baselines.
Klassische Fehler vermeiden
Alles testen, immer. Das ist die natürliche Reaktion und die schlechteste. Ihre Pipelines werden langsam, Ihre Entwickler ignorieren die Ergebnisse, weil es zu viel Rauschen gibt, und echte Bugs gehen in False Positives unter. Visuelles Testen im Monorepo muss chirurgisch sein.
Den Abhängigkeitsgraphen ignorieren. Manche Teams konfigurieren ihre visuellen Tests unabhängig vom Monorepo-Tool. Ergebnis: Die Tests wissen nicht, welche Projekte betroffen sind, und testen entweder alles oder nichts. Integrieren Sie Ihr visuelles Test-Tool mit Nx oder Turborepo. Nutzen Sie deren "affected"-Befehle, um die richtigen Tests auszulösen.
Alle Baselines in einen Ordner legen. Visuelle Baselines sollten neben den Projekten leben, die sie schützen. Wenn Sie alle Baselines in einem Root-Ordner zentralisieren, verlieren Sie die Granularität: Sie wissen nicht mehr, welche Baseline zu welchem Projekt gehört, und das Aufräumen veralteter Baselines wird unmöglich.
Baseline-Versionierung bei übergreifenden Updates vernachlässigen. Wenn Sie ein Design Token ändern, das alle Projekte betrifft, müssen alle Baselines gleichzeitig aktualisiert werden. Wenn Sie sie Projekt für Projekt in separaten PRs aktualisieren, schaffen Sie ein Fenster, in dem einige Projekte die neuen Baselines und andere die alten haben. Die Tests werden inkonsistent.
Die Rolle von CI/CD beim visuellen Testen im Monorepo
Die CI/CD-Konfiguration ist entscheidend. Ihre Pipeline muss drei Dinge können.
Erstens, die Menge der von der Änderung betroffenen Projekte berechnen. Das ist die Aufgabe von Nx (nx affected) oder Turborepo (turbo run --filter). Dieser Schritt bestimmt den Testumfang.
Zweitens, visuelle Tests pro Projekt parallelisieren. Wenn drei Anwendungen betroffen sind, starten Sie die Tests der drei Anwendungen parallel, nicht sequenziell. Jede Anwendung hat ihren eigenen Satz an Baselines und ihren eigenen Ergebnisbericht. Parallelisierung ist der einzige Weg, akzeptable Pipeline-Zeiten beizubehalten.
Drittens, Ergebnisse aggregieren und die PR bei Bedarf blockieren. Auch wenn die Tests parallelisiert sind, muss das Endurteil einheitlich sein: Die PR besteht oder besteht nicht. Wenn Anwendung A eine visuelle Regression hat und die anderen nicht, wird die PR blockiert. Der Entwickler weiß genau, welche Anwendung betroffen ist und kann untersuchen.
Wenn No-Code alles vereinfacht
Code-basierte visuelle Test-Tools — Playwright, Cypress mit visuellen Plugins — integrieren sich gut in ein Monorepo, weil sie im selben Repository neben dem Code leben, den sie testen. Aber sie fügen Testcode hinzu, der gewartet werden muss, Konfigurationen pro Projekt, spezifische CI/CD-Scripts.
No-Code-Tools wie Delta-QA bieten einen anderen Ansatz — besonders relevant, wenn Sie QA ohne Entwickler automatisieren möchten. Statt vom Quellcode aus zu testen, testen sie von den bereitgestellten URLs. Sie konfigurieren die URLs jeder Anwendung, das Tool erfasst Screenshots und vergleicht mit den Baselines. Das Monorepo ist kein Komplexitätsfaktor mehr — das Tool sieht nur URLs, keine Packages.
Der Nachteil: Sie profitieren nicht vom Abhängigkeitsgraphen zum Filtern der Tests. Der Vorteil: Die Konfiguration ist sofort, es gibt keinen Testcode zu pflegen, und der Test ist unabhängig von der Repository-Architektur. Für Teams ohne dedizierte Test-Entwickler ist das oft der richtige Kompromiss.
FAQ
Ist Nx oder Turborepo besser für visuelles Testen im Monorepo?
Nx hat einen signifikanten Vorteil dank seines detaillierteren Abhängigkeitsgraphen und seiner statischen Analyse-Plugins. Der Befehl nx affected identifiziert präzise die betroffenen Projekte, und Nx Executors ermöglichen die Integration visueller Testaufgaben in den Aufgabengraphen. Turborepo ist einfacher, bietet aber eine weniger granulare Filterung.
Wie verwaltet man Baselines, wenn ein Design Token sich ändert und alles betrifft?
Behandeln Sie es als übergreifendes Update. Erstellen Sie eine dedizierte PR, die den Token ändert und alle betroffenen Baselines in einer einzigen Operation aktualisiert. Führen Sie die vollständige Schicht visueller Tests aus, genehmigen Sie erwartete Änderungen als Batch und mergen Sie. Fragmentieren Sie ein Token-Update niemals in mehrere PRs — das öffnet die Tür für Inkonsistenzen.
Wie lange sollte ein visueller Test in einer Monorepo-Pipeline dauern?
Bei gezieltem Testen nur betroffener Projekte: weniger als 10 Minuten für eine Standard-PR, die ein einzelnes Projekt betrifft. Weniger als 20 Minuten für eine Änderung in einem Shared Package, das 3 bis 5 Projekte betrifft. Wenn Ihre Tests bei einer PR länger als 30 Minuten dauern, ist Ihre Filterstrategie unzureichend. Die vollständige Schicht (nightly) darf länger dauern — 30 bis 60 Minuten sind akzeptabel.
Braucht man separate Baselines pro Umgebung (Dev, Staging, Prod)?
Ja, wenn die Umgebungen unterschiedliche Inhalte oder Konfigurationen haben. Nein, wenn das Rendering identisch ist. In der Praxis pflegen Sie eine einzige Baseline pro Projekt, erfasst in einer stabilen Staging-Umgebung. Gegen die Produktion zu vergleichen ist verlockend, aber dynamischer Inhalt (Daten, Benutzerdaten, A/B-Tests) erzeugt zu viele False Positives.
Funktioniert visuelles Testen im Monorepo mit Lerna?
Lerna ist primär ein Tool für Versionsverwaltung und Package-Veröffentlichung. Sein Abhängigkeitsgraph ist weniger ausgeklügelt als der von Nx oder Turborepo. Sie können es verwenden, werden aber wahrscheinlich mit einem benutzerdefinierten Script ergänzen müssen, um betroffene Projekte zu identifizieren. Wenn Sie ein neues Monorepo starten, bevorzugen Sie Nx oder Turborepo.
Wie verhindert man, dass Entwickler die visuellen Testergebnisse ignorieren?
Drei Regeln. Halten Sie eine False-Positive-Rate nahe null — wenn Entwickler regelmäßig False Positives sehen, hören sie auf hinzuschauen. Blockieren Sie PRs bei visuellen Testfehlern — kein Merge ohne Genehmigung. Und halten Sie Pipeline-Zeiten kurz — wenn der visuelle Test 45 Minuten zur PR hinzufügt, werden Entwickler Wege finden, ihn zu umgehen.
Weiterführende Lektüre
- Delta-QA vs Screenshotbot: Desktop No-Code oder SaaS CI-First?
- Visueller Test und Lazy Loading: Seiten testen, die sich beim Scrollen aufbauen
Das Monorepo ist eine ausgezeichnete Architektur für Code-Sharing und Konsistenz. Aber ohne angepasste visuelle Teststrategie verwandelt es jede Änderung in eine Lotterie: Hat dieser Commit etwas in einem Projekt kaputtgemacht, das ich nicht einmal kenne? Die Antwort auf diese Frage sollte niemals "Ich weiß nicht" sein. Sie sollte automatisch, schnell und zuverlässig sein.