2 Commits

Include renames

Author	SHA1	Message	Date
RichardandClaude Opus 5	57cfca5fe9	Testlauf, dem man glauben kann: Zeitzonen-Tests und Schluss mit Nebenlaeufigkeit ... Zwei Tests zur Zeitzonen-Umstellung aus dem letzten Commit: der Zeitstempel eines Logeintrags traegt den Versatz der ANZEIGE-Zone (nicht den des Systems), und die abgelegte JSONL-Zeile traegt ihn mit. Sie liegen bewusst in AppTimeZoneTests - dort steht der uebrige Zeitzonen-Zustand, und innerhalb einer Klasse laufen Tests nacheinander. Das genuegte aber nicht. Von sechs Laeufen fiel einer um und liess sich danach nicht wieder einfangen. Die Ursache ist kein einzelner Test, sondern die Bauart: Mehrere Bausteine halten prozessweiten Zustand, den Tests bewusst umstellen - AppTimeZone, SecretProtection, die Diagnosezaehler von AccountIdSetJson. xUnit fuehrt Testklassen standardmaessig nebenlaeufig aus, also sieht eine Klasse mitten im eigenen Lauf, was eine andere gerade umgestellt hat. Neu ist das nicht, aber die Zeitzonen-Umstellung hat es verschaerft: Seit die Logzeitstempel der Anzeige-Zeitzone folgen, haengt jedes LogMessageEventArgs an AppTimeZone - waehrend AppTimeZoneTests dieselbe Einstellung nach Auckland und zurueck dreht. Deshalb laufen die Testklassen jetzt nacheinander, und die Zaehlerpruefungen arbeiten mit der Differenz statt mit absoluten Werten. Kosten: 4-5 s statt 3 s Laufzeit. Ein Testlauf, dem man glauben kann, ist das allemal wert - danach sechs Laeufe in Folge gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 21:06:18 +02:00
RichardandClaude Opus 5	9b2294cb4c	Testanleitung: eigenes X-Display je Projekt fuer Parallelbetrieb ... Damit mehrere Agenten gleichzeitig Oberflaechen testen koennen, bekommt jedes Projekt eine feste Displaynummer (Vorgabe Richard): :99 PolyTrader, :98 Predictalytics, :97 ClawdDotNet, :96 IBKRTrader, :95 und absteigend fuer kuenftige Projekte. Zwei Prozesse auf demselben Display sehen die Fenster des jeweils anderen - Klicks landen im falschen Programm, Aufnahmen zeigen fremde Anwendungen. Beim Durcharbeiten fielen zwei weitere Kollisionspunkte auf, die zum Parallelbetrieb dazugehoeren und mit aufgenommen wurden: - Screenshot- und Logdateien in /tmp brauchen ein Projektpraefix. /tmp/v_1.png ueberschreiben sich parallel laufende Projekte gegenseitig. - "xvfb-run -a" darf NICHT mehr verwendet werden: Das -a sucht sich selbst ein freies Display und beginnt dabei bei :99 - ausgerechnet PolyTraders Nummer. Stattdessen "xvfb-run -n <nummer>". Die Warnung ist nicht theoretisch: Auf der VM lag ein verwaister X98-Socket, entstanden durch genau so einen "xvfb-run -a"-Aufruf beim smoke-ui-Test, als :99 belegt war. Er blockierte Predictalytics' reservierte Nummer, ohne dass ein Prozess lief. Entfernt, und die Anleitung erklaert jetzt, wie man verwaiste Sockets erkennt (ls /tmp/.X11-unix/ gegen pgrep -a Xvfb lesen) und aufraeumt. Weiter ergaenzt: - pkill nie ohne Displaynummer - "pkill Xvfb" erschlaegt die Sitzungen aller anderen Projekte. - DISPLAY in jedem Skript setzen, sonst landet man auf :0, dem echten Desktop. - Die Skriptvorlage hat jetzt einen Kopf mit PROJEKT/DISP/FENSTER; das ist alles, was sich je Projekt unterscheidet. Praktisch gegengetestet. - Aufraeumabschnitt und Belegungsliste um Displays und Verzeichnisse erweitert. Nebenbei aufgefallen: Das PolyTrader-Publish lag unter ~/pt-test statt ~/polytrader-test und verletzte damit die eigene Verzeichniskonvention. Umbenannt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 20:49:28 +02:00