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 Abhaengigkeitsgraphen optimieren.
Monorepos haben gewonnen. Frontend-Teams, die mehrere Anwendungen verwalten — eine Marketing-Website, ein Admin-Dashboard, eine Kunden-App, ein Partner-Portal — buendeln sie in einem einzigen Repository. Das ist einfacher fuer Code-Sharing, konsistenter fuer das Design System, effizienter fuer uebergreifende Aktualisierungen.
Aber fuer 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 Aenderung in einem Shared Package loest potenziell visuelle Tests auf allen Projekten aus, die davon abhaengen. Und wenn Ihr Monorepo 15, 30 oder 50 Projekte enthaelt, ist "alles bei jedem Commit testen" keine Option mehr.
Das Grundproblem: Der Abhaengigkeitsgraph
In einem Monorepo sind Projekte nicht unabhaengig. Sie teilen Packages: ein Design System, eine Utility-Bibliothek, gemeinsame Komponenten, geteilte Konfigurationen. Diese Abhaengigkeiten 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 enthaelt. Dieses Package wird von 12 Anwendungen in Ihrem Monorepo verwendet. Sie aendern das Padding eines Buttons in "ui-components". Visuell betrifft diese Aenderung potenziell alle 12 Anwendungen. Jede Seite, die einen Button enthaelt, koennte 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 fehlschlaegt — 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 geaendert 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 Aenderung betroffen ist.
Moderne Monorepo-Tools — Nx und Turborepo an der Spitze — koennen den Abhaengigkeitsgraphen berechnen und die "betroffenen" Projekte einer Aenderung identifizieren. Wenn Sie eine Datei im Package "ui-components" aendern, kann Nx Ihnen sagen, dass die Anwendungen A, C, F und K von diesem Package abhaengen, aber nicht B, D und die anderen.
Das ist die Basis. Aber fuer visuelles Testen reicht das nicht aus. Denn "Anwendung A haengt von ui-components ab" bedeutet nicht, dass alle Seiten von Anwendung A die geaenderte Komponente verwenden. Wenn Sie den Button geaendert 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 Aenderung betroffen, laut Abhaengigkeitsgraph. Zweite Ebene: Welche Seiten oder Komponenten dieser Projekte verwenden tatsaechlich das geaenderte Element.
Die erste Ebene wird von den Monorepo-Tools geloest. 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 Realitaet der Shared Packages
Shared Packages sind die Staerke und die Schwaeche des Monorepos. Sie ermoeglichen Konsistenz: ein einziges Design System, eine einzige Wahrheitsquelle fuer visuelle Komponenten. Aber sie erzeugen auch einen erheblichen Blast Radius.
Es gibt drei Arten von Shared Packages, die spezifische Probleme fuer visuelles Testen verursachen.
UI-Komponenten-Packages. Das ist der offensichtlichste Fall. Eine Aenderung an einem Button, Formular oder Modal betrifft visuell alle Seiten, die sie verwenden. Der Blast Radius ist proportional zur Popularitaet der Komponente. Eine Layout-Komponente, die ueberall verwendet wird (Header, Footer, Sidebar), hat maximalen Blast Radius.
Style- und Token-Packages. Eine Aenderung an Design Tokens — Farben, Abstaende, Typografie — ist im traditionellen Abhaengigkeitsgraphen oft unsichtbar. Wenn Sie die Primaerfarbe in Ihrer Token-Datei aendern, sieht der Abhaengigkeitsgraph eine Aenderung im Package "design-tokens". Aber diese Aenderung betrifft visuell alles: jeden primaeren 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 kuerzen oder Layouts berechnen. Eine Aenderung an einer Textkuerzungsfunktion — von 100 auf 80 Zeichen Maximum — hat einen direkten visuellen Einfluss auf alle Komponenten, die sie verwenden. Aber der Abhaengigkeitsgraph weiss nicht, dass es eine "visuelle" Aenderung 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 Ausfuehrungsfrequenzen.
Die Komponenten-Schicht. Testen Sie jede Design-System-Komponente isoliert, ueber Storybook oder Aequivalent. Diese Tests werden nur ausgefuehrt, wenn sich das Komponenten-Package aendert. Sie sind schnell (einige Minuten) und schuetzen die Bibliothek selbst. Das ist das erste Netz, wie im Artikel ueber visuelle Tests in Design Systems beschrieben.
Die Seiten-Schicht — betroffen. Testen Sie die Seiten der von der Aenderung betroffenen Anwendungen, identifiziert durch den Abhaengigkeitsgraphen. Diese Tests laufen bei jedem Pull Request, aber nur auf den betroffenen Projekten. Sie sind das Herzsstueck Ihrer Strategie.
Die vollstaendige Schicht. Testen Sie alle Seiten aller Anwendungen. Diese Schicht wird nicht bei jeder PR ausgefuehrt — das ist zu teuer. Fuehren Sie sie einmal taeglich (nightly) oder vor jedem Release aus. Wie in unserem Leitfaden zur visuellen Ueberwachung in der Produktion beschrieben, faengt diese Schicht Regressionen ab, die der Abhaengigkeitsgraph 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 aendert, 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 muehsam. Aber es kann automatisch durch statische Code-Analyse generiert werden — durch Durchlaufen der Imports jeder Seite und Zurueckverfolgen der Abhaengigkeiten. Nx bietet Plugins an, die diese Art von Analyse erleichtern.
Der Vorteil ist betraechtlich: Statt 200 Seiten von Anwendung A zu testen, wenn sich eine Komponente aendert, 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 koennen daher eine Design-System-Baseline auf Package-Ebene pflegen und Baselines auf Anwendungsebene nur dann neu erfassen, wenn sich der Integrationskontext aendert.
Konkret: Wenn Sie die Button-Komponente aendern, 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 natuerliche 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 Abhaengigkeitsgraphen ignorieren. Manche Teams konfigurieren ihre visuellen Tests unabhaengig 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 auszuloesen.
Alle Baselines in einen Ordner legen. Visuelle Baselines sollten neben den Projekten leben, die sie schuetzen. Wenn Sie alle Baselines in einem Root-Ordner zentralisieren, verlieren Sie die Granularitaet: Sie wissen nicht mehr, welche Baseline zu welchem Projekt gehoert, und das Aufraaeumen veralteter Baselines wird unmoeglich.
Baseline-Versionierung bei uebergreifenden Updates vernachlaessigen. Wenn Sie ein Design Token aendern, das alle Projekte betrifft, muessen alle Baselines gleichzeitig aktualisiert werden. Wenn Sie sie Projekt fuer 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 koennen.
Erstens, die Menge der von der Aenderung 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 weiss 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 fuegen 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 moechten. 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 Komplexitaetsfaktor mehr — das Tool sieht nur URLs, keine Packages.
Der Nachteil: Sie profitieren nicht vom Abhaengigkeitsgraphen zum Filtern der Tests. Der Vorteil: Die Konfiguration ist sofort, es gibt keinen Testcode zu pflegen, und der Test ist unabhaengig von der Repository-Architektur. Fuer Teams ohne dedizierte Test-Entwickler ist das oft der richtige Kompromiss.
FAQ
Ist Nx oder Turborepo besser fuer visuelles Testen im Monorepo?
Nx hat einen signifikanten Vorteil dank seines detaillierteren Abhaengigkeitsgraphen und seiner statischen Analyse-Plugins. Der Befehl nx affected identifiziert praezise die betroffenen Projekte, und Nx Executors ermoeglichen 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 aendert und alles betrifft?
Behandeln Sie es als uebergreifendes Update. Erstellen Sie eine dedizierte PR, die den Token aendert und alle betroffenen Baselines in einer einzigen Operation aktualisiert. Fuehren Sie die vollstaendige Schicht visueller Tests aus, genehmigen Sie erwartete Aenderungen als Batch und mergen Sie. Fragmentieren Sie ein Token-Update niemals in mehrere PRs — das oeffnet die Tuer fuer Inkonsistenzen.
Wie lange sollte ein visueller Test in einer Monorepo-Pipeline dauern?
Bei gezieltem Testen nur betroffener Projekte: weniger als 10 Minuten fuer eine Standard-PR, die ein einzelnes Projekt betrifft. Weniger als 20 Minuten fuer eine Aenderung in einem Shared Package, das 3 bis 5 Projekte betrifft. Wenn Ihre Tests bei einer PR laenger als 30 Minuten dauern, ist Ihre Filterstrategie unzureichend. Die vollstaendige Schicht (nightly) darf laenger 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 primaer ein Tool fuer Versionsverwaltung und Package-Veroeffentlichung. Sein Abhaengigkeitsgraph ist weniger ausgeklueggelt als der von Nx oder Turborepo. Sie koennen es verwenden, werden aber wahrscheinlich mit einem benutzerdefinierten Script ergaenzen muessen, 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 regelmaessig False Positives sehen, hoeren 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 hinzufuegt, 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 fuer Code-Sharing und Konsistenz. Aber ohne angepasste visuelle Teststrategie verwandelt es jede Aenderung in eine Lotterie: Hat dieser Commit etwas in einem Projekt kaputtgemacht, das ich nicht einmal kenne? Die Antwort auf diese Frage sollte niemals "Ich weiss nicht" sein. Sie sollte automatisch, schnell und zuverlaessig sein.