RichardandClaude Opus 5
57cfca5fe9
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>
18 lines
1002 B
C#
18 lines
1002 B
C#
using Xunit;
|
|
|
|
// Testklassen laufen NACHEINANDER, nicht parallel.
|
|
//
|
|
// Warum: Mehrere Bausteine der Anwendung halten prozessweiten Zustand, und die Tests stellen ihn
|
|
// bewusst um — AppTimeZone (Anzeige-Zeitzone), SecretProtection (Master-Key) und die
|
|
// Diagnosezähler von AccountIdSetJson. xUnit führt Testklassen standardmäßig nebenläufig aus;
|
|
// dann sieht eine Klasse die Umstellung einer anderen mitten im eigenen Lauf.
|
|
//
|
|
// Das ist nicht theoretisch: Seit die Logzeitstempel der Anzeige-Zeitzone folgen (§8 des
|
|
// Linux-Befundberichts vom 26.08.2026), hängt jedes LogMessageEventArgs an AppTimeZone — während
|
|
// AppTimeZoneTests dieselbe Einstellung nach Auckland und zurück dreht. Am 28.08.2026 fiel dabei
|
|
// ein Lauf von sechs um, ohne sich danach wieder einfangen zu lassen.
|
|
//
|
|
// Der Preis ist gering: Der gesamte Satz läuft in rund drei Sekunden. Ein Testlauf, dem man
|
|
// glauben kann, ist das allemal wert.
|
|
[assembly: CollectionBehavior(DisableTestParallelization = true)]
|