Testen und Debuggen

Testen und Debuggen

0:00 Beim Thema Tests kommt in Forge-Projekten regelmäßig ein Einwand: Die Oberfläche lässt sich ohne DOM nicht so testen, wie wir das gewohnt sind. Das stimmt. Nur ist es kein Grund, weniger zu testen — es ist ein Grund, anders zu schneiden. Was nicht rendert, lässt sich hervorragend prüfen, und das ist der größere Teil des wertvollen Codes: Regeln, Prüfungen, Statuslogik.

0:22 Dazu kommt die Fehlersuche mit den Mitteln der Plattform, die überraschend gut ist, wenn man die Reihenfolge kennt. Beides schauen wir uns in diesem Modul an.

Testen und Debuggen

0:32 Dieser zweite Teil des vierten Tages ist die praktische Ergänzung zum Sicherheitsvormittag. Eine Prüfung, die nicht getestet ist, ist eine Absicht. Wir schauen uns an, wie man Fachlogik testbar schneidet, wie man an den Grenzen mit Attrappen arbeitet, was manuell geprüft gehört — und wie man einen Fehler eingrenzt, der sich nur in der Produktion zeigt.

Unit-Tests für Fachlogik

0:52 Beginnen wir mit dem Teil, der am einfachsten ist — und deshalb am häufigsten vergessen wird. Fachliche Regeln hängen nicht an Forge. Ob ein Statuswechsel erlaubt ist, wie sortiert wird, welche Länge ein Titel haben darf — das ist gewöhnliches JavaScript. Wenn diese Regeln in eigenen Funktionen liegen statt mitten im Resolver oder in der Komponente, laufen die Tests mit einem gewöhnlichen Testwerkzeug: schnell, ohne Instanz, ohne Ausrollen.

1:17 Das klingt nach einer Selbstverständlichkeit, ist aber in der Praxis die entscheidende Weiche. Sie fällt beim Schreiben des Codes, nicht beim Schreiben der Tests. Oben eine Regel in zwei Zeilen, unten der Test dazu. Worauf es ankommt: Die Regel hat einen Namen und einen Ort. Sie lässt sich aufrufen, ohne dass ein Vorgang, eine Nutzerin oder ein Speicher existiert.

1:39 Deshalb kann der Test sie mit beliebig vielen Kombinationen durchrechnen — auch mit denen, die man in der Oberfläche nur mühsam herbeiführt. Die Fußzeile schließt den Kreis: Der Resolver ruft dieselbe Funktion auf. Die Regel wird einmal geschrieben und einmal geprüft, und das ist mehr wert, als es aussieht. Vier Gründe, und sie laufen alle auf dieselbe Einsicht hinaus: Testbarkeit ist eine Eigenschaft des Schnitts, nicht der Testwerkzeuge.

2:06 In der Komponente ist dieselbe Regel ohne DOM nicht prüfbar. Im Resolver braucht sie Kontext, Speicher und damit Attrappen. Eigenständig lässt sie sich durchrechnen. Und der letzte Punkt ist der, den ich für den wichtigsten halte: Die Regel bleibt auffindbar, wenn sie einen Namen hat. In einem halben Jahr sucht jemand „wo wird eigentlich entschieden, ob…" — und findet es.

2:29 Der erste Punkt ist die direkte Folge eines falschen Schnitts: Die Prüfung steht in der Formularkomponente und gilt damit nur dort — die Sicherheitsfolgen kennen wir seit heute Vormittag. Der zweite ist der Klassiker aus allen Projekten: getestet werden Erfolgsfälle. Die Grenzwerte, bei denen es interessant wird, bleiben ungeprüft.

2:47 Und der dritte ist eine Frage der Test-Qualität: Wer die Umsetzung testet statt das Verhalten, muss bei jeder Refaktorierung die Tests umschreiben — und schafft sie irgendwann ab.

Tests an den Grenzen

2:58 Jetzt dorthin, wo die Fehler tatsächlich sitzen: an die Grenzen zwischen Ihrem Code und der Plattform. An den Grenzen liegen die Fehler — Resolver-Aufrufe, Produkt-APIs, Speicherzugriffe. Hier arbeiten Sie mit Attrappen: Das Speicherpaket, die Bridge oder die HTTP-Antwort werden ersetzt. Und jetzt kommt der Punkt, den man leicht falsch versteht: Geprüft wird nicht die Attrappe, sondern was Ihre eigene Funktion mit der Antwort macht.

3:24 Kommt eine leere Antwort zurück — was passiert? Antwortet der Speicher gar nicht — was sieht die Nutzerin? Das sind die interessanten Fragen, und sie lassen sich hier sehr genau stellen. Oben wird das Speicherpaket durch eine Attrappe ersetzt — zwei Zeilen, und der Test kommt ohne Plattform aus. Unten der eigentliche Prüfpunkt: Ein ungültiger Statuswert wird abgewiesen, und zwar mit dem vorgesehenen Grund.

3:49 Worauf es ankommt: Der Test prüft die Rückgabeform, nicht nur, dass „irgendein Fehler" passiert. Genau diese Form hat die Oberfläche gestern genutzt, um eine präzise Meldung anzuzeigen. Ändert sich die Form, bricht der Test — und das ist erwünscht, denn sonst bräche später die Oberfläche. Der rote Faden: Zuerst der Schnitt, dann die Attrappen, dann die Fälle. Schritt drei nennt drei Fälle, und der dritte wird fast immer vergessen — der Ausfall der Gegenstelle.

4:18 Jeder Speicher antwortet irgendwann nicht, jede API hat einen schlechten Tag. Wenn Ihre App dann eine unbehandelte Ausnahme wirft, sieht die Nutzerin einen technischen Text. Schritt vier ist die Erinnerung, die Antwortform festzuschreiben. Und Schritt fünf ist die Disziplin, die Tests mitzuziehen, wenn sich diese Form ändert.

4:38 Der erste Punkt ist der häufigste Fehler beim Arbeiten mit Attrappen: Am Ende prüft der Test, dass die Attrappe aufgerufen wurde — also im Grunde, dass der Code so aussieht, wie er aussieht. Der zweite kennen wir schon: Der Ausfall der Gegenstelle bleibt ungeprüft. Und der dritte ist der gefährlichste im Projektalltag: Tests laufen gegen eine echte Instanz und ändern dort Daten.

4:59 Das ist schnell gebaut, fühlt sich gründlich an und macht die Instanz unbrauchbar für alle anderen.

Manuelle Prüfungen in der Instanz

5:05 Manches lässt sich nicht automatisieren. Genau dafür braucht es keine Intuition, sondern eine Liste. Darstellung, Berechtigungen, Lebenszyklus — das prüft man von Hand. Die Frage ist nur, ob systematisch oder zufällig. Die meisten Teams klicken herum, finden nichts und fühlen sich sicher. Eine feste Liste dreht das um: Installation, Upgrade, Deinstallation, verschiedene Rollen, leere Daten, Fehleingaben, mehrfache Aktionen.

5:33 Das dauert zwanzig Minuten und findet Dinge, die im Herumklicken nie auffallen — weil man als Entwicklerin unbewusst immer den Weg nimmt, den man gebaut hat. Lesen Sie diese Liste nicht als Vorgabe, sondern als Startpunkt für Ihre eigene. Die Logik dahinter: Jede Zeile prüft einen Zustand, den Ihre Entwicklung nie erzeugt.

5:53 Frisch installiert haben Sie zuletzt vor Wochen. Ein Upgrade mit neuem Scope betrifft Sie nicht, weil Sie ohnehin alles dürfen. Ein Konto ohne Schreibrecht besitzen Sie meistens gar nicht — besorgen Sie sich eins, es lohnt sich. Und die Fußzeile ist die wichtigste Zeile der Folie: geprüft wird auf einer sauberen Instanz, nicht auf der Entwicklungsinstanz mit ihren Altlasten.

6:16 Alle drei Punkte beschreiben dieselbe Blindheit. Geprüft wird mit dem eigenen Konto, das alle Rechte hat — also sieht man den Berechtigungsfall nie. Geprüft wird die Erstinstallation, nie das Upgrade — und genau beim Upgrade hängt später die halbe Kundschaft. Und die Liste entsteht jedes Mal neu, wodurch bei jeder Freigabe andere Fälle geprüft werden.

6:36 Schreiben Sie die Liste einmal auf und pflegen Sie sie; sie wird mit jedem gefundenen Fehler besser.

Fehlersuche mit den Plattformmitteln

6:43 Bleibt der Fall, der im Alltag am meisten Nerven kostet: Etwas geht schief, und zwar nicht bei Ihnen. Sie haben vier Mittel, und sie greifen in einer sinnvollen Reihenfolge ineinander. Lint prüft Projekt und Manifest, bevor überhaupt ausgerollt wird. Der Tunnel zeigt die Ausgaben lokalen Codes. Die Protokollabfrage holt die Ausgaben der ausgerollten App, je Umgebung.

7:06 Und die Entwicklerkonsole zeigt Metriken und Fehlerraten über längere Zeiträume. Neu hinzugekommen sind im September 2026 Frontend-Protokolle im Frühzugang — bis dahin war die Oberfläche der blinde Fleck bei der Fehlersuche. Vier Befehle, die Sie sich ins Notizbuch schreiben sollten. Interessant ist vor allem der dritte: Die Protokolle gehören immer zu einer Umgebung.

7:29 Wer ohne Angabe abfragt, landet in der Entwicklungsumgebung und wundert sich, warum dort nichts steht, obwohl doch gerade ein Fehler gemeldet wurde. Der vierte Befehl zeigt die Zeitspanne — meist die schnellste Eingrenzung, wenn jemand sagt „vor zehn Minuten ging es nicht". Und die Fußzeile erinnert daran, dass Metriken nicht im Terminal stehen, sondern in der Konsole.

7:51 Der rote Faden ist eine Reihenfolge, die von billig nach teuer geht. Zuerst das Symptom sauber festhalten: Wer, wo, welche Aktion, welche Meldung. Das allein löst überraschend viele Fälle. Dann Lint, um Manifest-Ursachen auszuschließen. Dann der Versuch, es im Tunnel nachzustellen. Lässt es sich nicht nachstellen, kommen die Protokolle der betroffenen Umgebung.

8:13 Und wenn es sporadisch ist, grenzen Metriken ein, wann es auftritt — oft zeigt sich dann ein Muster, etwa immer nach einem Release oder immer bei vielen gleichzeitigen Zugriffen. Der erste Punkt kostet die meiste Zeit: Gesucht wird im Tunnel, aber der Fehler tritt nur in der Produktion auf — weil dort andere Daten, andere Rechte, andere Mengen herrschen.

8:33 Der zweite ist der Befehl ohne Umgebungsangabe, der leere Protokolle liefert und eine falsche Sicherheit erzeugt. Und der dritte ist der strukturelle: Ein Fehler in der Oberfläche hinterlässt keine Spur im Backend-Protokoll. Genau deshalb sind die neuen Frontend-Protokolle eine willkommene Ergänzung, auch wenn man sich im Frühzugang noch nicht darauf verlassen sollte.

Übung

8:54 In der Übung machen Sie beides: Sie sichern zwei kritische Abläufe ab und grenzen einen vorbereiteten Fehler ein. Klarpfad ist funktionsfähig, aber ungeprüft — ein Zustand, den man aus echten Projekten kennt. Zwei Abläufe sind kritisch: das Anlegen einer gültigen Entscheidung und die Ablehnung einer ungültigen Eingabe. Zusätzlich liegt ein vorbereiteter Fehler bereit, bei dem eine Nutzerin ohne Schreibrecht eine unverständliche Meldung sieht.

9:21 Dieser zweite Teil ist die eigentliche Übung: Nicht das Beheben zählt, sondern der Weg vom Symptom zur Ursache. Zwei Erfolgskriterien, und beide sind bewusst bescheiden. Zwei Tests laufen ohne Instanz durch — mehr braucht es nicht, um den Punkt zu machen. Und der Weg vom Symptom zur Ursache ist schriftlich belegt. Schreiben Sie diesen Weg wirklich auf, mit den Zwischenschritten, auch den falschen.

9:45 Das ist die Art Notiz, die beim nächsten Fehler eine Stunde spart. Wer früh fertig ist, ergänzt einen Test für den Ausfall der Speicher-Gegenstelle — den Fall, der im Betrieb garantiert kommt. Schritt eins ist der eigentliche Lerninhalt: die Prüfregel aus dem Resolver in eine eigene Funktion ziehen. Alles Weitere folgt daraus fast von selbst.

10:06 Die Schritte zwei und drei sind Handwerk mit Attrappe. Schritt vier führt Sie in die Instanz, und Schritt fünf verlangt Disziplin: Lint, Tunnel und Protokolle der Reihe nach — nicht durcheinander, sondern in dieser Ordnung, und mit Notizen. Genau dieses Vorgehen brauchen Sie später, wenn ein Kunde anruft und Sie den Fehler nicht nachstellen können.

10:26 Drei Punkte zum Mitnehmen. Der Test greift auf den echten Speicher zu und ändert Daten — was vor allem dann unangenehm ist, wenn jemand anderes gerade darin arbeitet. Die Diagnose endet beim Symptom, und die Ursache bleibt Vermutung; dann kommt derselbe Fehler in vier Wochen wieder. Und der dritte ist der leiseste Rückschritt: Der Fehler wird behoben, ohne den Test dafür zu ergänzen.

10:48 Im nächsten Modul sehen wir, warum Tests noch wichtiger werden, sobald Code nicht mehr nur von Menschen geschrieben wird.