UI-Komponenten dort prüfen, wo sie ausgeliefert werden: in der Seite

Für sich allein kann eine Komponente pixelgenau aussehen und in der ausgelieferten Seite trotzdem kaputt sein. Um genau diese Lücke herum hat Memo seinen UI Verifier gebaut. Ein genauer Blick lohnt sich, weil die interessante Entscheidung im Wie der Verifikation liegt und nicht darin, dass überhaupt verifiziert wird. Die Automation-Datei des UI Verifiers (öffnet in einem neuen Tab) liegt auf GitHub.

Er läuft bei jedem Merge, der UI berührt

Sobald ein Pull Request gemergt ist, startet er. Ausgelöst wird er vom Merge-Event selbst, einen Zeitplan gibt es nicht. Hat der Merge keine UI-Datei berührt, ist an dieser Stelle schon Schluss.

Zuerst ein statischer Durchlauf gegen die Designregeln

Hat sich die UI geändert, fängt die Arbeit an. Im ersten Schritt liest er die Designregeln und gleicht den Diff statisch damit ab. Geprüft werden Farb-Tokens, Typo-Skala, Abstände, Button-Varianten, Lade- und Leerzustände, Transitions, Barrierefreiheit und Dark Mode. Beliebige Hex-Werte fallen durch, Schriftgrößen außerhalb der Skala ebenso.

Dann zwei Screenshots jeder geänderten Komponente

Im zweiten Schritt geht es ums Bild. Jede geänderte Komponente hält er zuerst isoliert per Screenshot fest, und zwar in der Komponenten-Workbench. Danach folgt ein Screenshot derselben Komponente auf der Live-Site, im gleichen Desktop-Viewport. Dann vergleicht er beide Bilder nebeneinander.

Genau diesen Vergleich solltet ihr euch abschauen. In der Workbench seht ihr eine Komponente unter perfekten Bedingungen. Auf der Live-Seite wirken Layout-Vorgaben der Eltern-Container, die CSS-Kaskade, fehlende Verdrahtung und abgeschnittener Overflow mit. Ein Datepicker, der allein einwandfrei rendert, wird im echten Formular womöglich wieder zum schlichten Eingabefeld. Das fällt nur im Vergleich nebeneinander auf.

Findet er einen Verstoß, legt er ein konkretes Issue an: Datei, Zeile und was die Design-Spec an dieser Stelle tatsächlich sagt. Ist alles in Ordnung, meldet er sich nicht.

Eure Nutzer sehen nie die isolierte Komponente

Teams, die ihre eigenen Checks bauen, sage ich das immer wieder. Visuelle Verifikation testet meist die Komponente, weil sie sich leicht isolieren lässt. Nur bekommen eure Nutzer die isolierte Komponente nie zu sehen. Bei ihnen steckt sie eingebettet, tief in einer echten Seite. Wer nur in Isolation prüft, prüft etwas, das so nie ausgeliefert wird.

Zur Verifikation gehört der Integrationskontext dazu. Isolierte Tests beruhigen, die Integrationsansicht sagt euch, wie es wirklich ist. Automatisieren lässt sich beides billig, sobald ihr die zweite Ansicht zur Pflicht erklärt.

Wenn ein UI-Bug eure Nutzer erreicht: Lag der Fehler dann meist in der Komponente selbst oder in der Seite, in der sie gelandet ist?

Weiterlesen

Die Artikel der Wissensbasis sind auf Englisch.

• The surrounding quality system →
• Agentic Software Factory: Advanced Team Training →