Files
IBKRTrader/tests/IBKRTrader.Tests/Workers/WorkerBaseTests.cs
T
RichardandClaude Opus 5 084cd7ef77
Build & Test / build (ubuntu-latest) (push) Canceled after 0s
Build & Test / build (windows-latest) (push) Canceled after 0s
Options-Fundament und Kapitalmodell im Core; Modul OptionsWheel
Das OptionsWheel setzt auf Dingen auf, die es im Core nicht gab. Diese
Sitzung baut sie.

#298 Optionen als Instrument. InstrumentKind/OptionSpec und ein
druckbarer Instrumentenschluessel ("AAPL|20260918|C|150"); TradeSignal
und OrderRequest tragen ein optionales OptionSpec, ohne das sich der
Aktienpfad unveraendert verhaelt. Position.Notional rechnet ab jetzt mit
der Kontraktgroesse - vorher war jede Option um Faktor 100 zu klein
bewertet und damit jedes Risikolimit wirkungslos, lautlos und in die
gefaehrliche Richtung. Daneben neu BoundCapital: ein Short Put bindet
Strike x Kontraktgroesse, nicht die vereinnahmte Praemie.

#300 sell-to-open. Jeder Auftrag zerfaellt in einen schliessenden und
einen eroeffnenden Teil; der schliessende wird von keinem Limit
verhindert - auch nicht vom Kaufstopp, denn ein Rueckkauf baut eine
Verpflichtung ab. Deckungspruefung im Core, nicht im Modul: Short Call
nur mit freien Aktien, Short Put nur mit reservierbarem Bargeld.

#302-#305 Kapital- und Buchmodell. Buecher mit reservierten Namen und
Eigentumsregeln, Pool mit Caps und Headroom, Margin-Sperre in vier
Schichten, core_reservation mit Lebenszyklus, Frist, Idempotenz ueber
(SignalId, ContractKey) und Quarantaene beim Start.

#309/#310 Modul OptionsWheel: ow_-Schema mit fuenf Tabellen,
Zustandsautomat, StrikeSelector, RollDecider, PremiumMath - vollstaendig
ohne Broker testbar. Der Handelsbetrieb bleibt gesperrt, solange #299
und #294 fehlen; das Modul sagt das ueber GetActivationBlocker, statt
still nichts zu tun.

#293 --verify-order am Daemon: eine Order durch die vollstaendige Kette
(Buch, Risiko, Bindung, Order, Fill, Buchung, Abschluss). Ohne --confirm
ein Trockenlauf; Abbruch ausserhalb von Paper-Modus UND Paper-Port.

Drei Widersprueche in den Konzepten sind dabei entschieden worden:
Schicht B heisst ab jetzt "kein UNGEDECKTER Short" (der Grund der Regel
war der Kredit, nicht der Short), die Hausreserve wird einmal abgezogen
statt zweimal, und der Positionsschluessel ist eine Spalte statt eines
Sechser-Verbunds (MySQL verlangt NOT NULL fuer Schluesselspalten).
Begruendungen stehen in docs/ROADMAP.md.

Enthaelt ausserdem die noch nicht committete Arbeit aus der vorigen
Sitzung: die Fehlerbehebungen aus Epic X (WorkerBase-Intervall,
BackupWorker, --check gegen die Datenbank, CapitolTrades-429, SIGTERM)
samt DatabaseEndpoint, MysqlDumpTool und der Roadmap-Umstellung. Sie lag
im Arbeitsbaum und liess sich nicht abtrennen, weil beide Staende
dieselben Dateien beruehren.

213 -> 369 Tests, Build ohne Warnung.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-04 09:35:38 +02:00

174 lines
6.5 KiB
C#
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
using System.Diagnostics;
using FluentAssertions;
using IBKRTrader.Core.Logging;
using IBKRTrader.Core.Persistence.Ef;
using IBKRTrader.Core.Workers;
using Microsoft.EntityFrameworkCore;
namespace IBKRTrader.Tests.Workers;
[Trait("cat", "unit")]
public class WorkerBaseTests
{
/// <summary>
/// Testbarer Worker: überschreibt den DB-Log-Seam (kein MySQL-Zugriff) und
/// zählt seine Läufe. Zustände werden per Polling geprüft, weil WorkerBase
/// Info.Status intern (und nach dem Log-Abschluss) setzt.
/// </summary>
private sealed class TestWorker : WorkerBase
{
private readonly TimeSpan? _interval;
private readonly Func<CancellationToken, Task> _body;
public int Runs;
public override string Name => "TestWorker";
public override string Module => "TEST";
protected override TimeSpan? Interval => _interval;
private sealed class InMemoryFactory(DbContextOptions<CoreDbContext> o) : IDbContextFactory<CoreDbContext>
{
public CoreDbContext CreateDbContext() => new(o);
}
private static IDbContextFactory<CoreDbContext> Dbf() =>
new InMemoryFactory(new DbContextOptionsBuilder<CoreDbContext>()
.UseInMemoryDatabase(Guid.NewGuid().ToString()).Options);
public TestWorker(TimeSpan? interval, Func<CancellationToken, Task> body)
: base(new LoggingService(), Dbf())
{
_interval = interval;
_body = body;
}
protected override async Task ExecuteAsync(CancellationToken ct)
{
Interlocked.Increment(ref Runs);
await _body(ct);
}
// Seam überschreiben → kein DB-Zugriff. Positive Id, damit die End-Log-Aufrufe
// (in WorkerBase mit `logId > 0` geschützt) auch im Fehlerpfad laufen.
protected override Task<long> BeginRunLogAsync() => Task.FromResult(1L);
protected override Task EndRunLogAsync(long logId, bool success, string? message = null)
=> Task.CompletedTask;
}
private static readonly TimeSpan Timeout = TimeSpan.FromSeconds(5);
private static async Task WaitUntilAsync(Func<bool> condition, string because)
{
var sw = Stopwatch.StartNew();
while (!condition())
{
if (sw.Elapsed > Timeout)
throw new TimeoutException($"Bedingung nicht innerhalb {Timeout.TotalSeconds}s erfüllt: {because}");
await Task.Delay(15);
}
}
[Fact]
public async Task RunsOnce_WhenIntervalIsNull_AndReportsIdle()
{
var worker = new TestWorker(interval: null, _ => Task.CompletedTask);
await worker.StartAsync(CancellationToken.None);
// Hinweis: WorkerBase startet bereits im Zustand Idle – deshalb auf den
// abgeschlossenen Lauf warten (Runs == 1 UND wieder Idle).
await WaitUntilAsync(
() => worker.Runs == 1 && worker.Info.Status == WorkerStatus.Idle,
"ein Lauf ist abgeschlossen und Status zurück auf Idle");
worker.Runs.Should().Be(1);
await worker.StopAsync(CancellationToken.None);
}
[Fact]
public async Task Trigger_ForcesImmediateRun_BeforeIntervalElapses()
{
// Langes Intervall → ein zweiter Lauf kann nur durch Trigger entstehen.
var worker = new TestWorker(TimeSpan.FromMinutes(10), _ => Task.CompletedTask);
await worker.StartAsync(CancellationToken.None);
await WaitUntilAsync(() => worker.Runs == 1, "erster Lauf erfolgt");
await worker.TriggerAsync();
await WaitUntilAsync(() => worker.Runs == 2, "Trigger löst zweiten Lauf aus");
await worker.StopAsync(CancellationToken.None);
}
[Fact]
public async Task Exception_SetsStatusError_AndCapturesMessage()
{
var worker = new TestWorker(interval: null,
_ => throw new InvalidOperationException("boom"));
await worker.StartAsync(CancellationToken.None);
await WaitUntilAsync(() => worker.Info.Status == WorkerStatus.Error, "Status wird Error");
worker.Runs.Should().Be(1);
worker.Info.Info.Should().Contain("boom");
await worker.StopAsync(CancellationToken.None);
}
[Fact]
public async Task Stop_SetsStatusStopped()
{
var worker = new TestWorker(TimeSpan.FromMinutes(10), _ => Task.CompletedTask);
await worker.StartAsync(CancellationToken.None);
await WaitUntilAsync(() => worker.Runs == 1, "erster Lauf erfolgt");
await worker.StopAsync(CancellationToken.None);
worker.Info.Status.Should().Be(WorkerStatus.Stopped);
}
/// <summary>
/// Intervalle über 24,85 Tage (int.MaxValue Millisekunden) beendeten den Worker früher still:
/// SemaphoreSlim.WaitAsync wirft darüber, die Ausnahme verließ den Lauf-Loop, der Task
/// faultete – und riss beim Herunterfahren den ganzen Prozess mit.
/// Zwei ausgelieferte Vorgaben lagen über der Grenze.
/// </summary>
[Fact]
public async Task VeryLongInterval_KeepsWorkerAlive_AndStopsCleanly()
{
var worker = new TestWorker(TimeSpan.FromDays(400), _ => Task.CompletedTask);
await worker.StartAsync(CancellationToken.None);
await WaitUntilAsync(() => worker.Runs == 1, "erster Lauf erfolgt");
// Der Trigger beweist, dass die Warteschleife lebt statt an einer Ausnahme gestorben zu sein.
await worker.TriggerAsync();
await WaitUntilAsync(() => worker.Runs == 2, "die Warteschleife nimmt weiter Trigger an");
worker.Info.Status.Should().NotBe(WorkerStatus.Error);
// Kein erneutes Werfen beim Stoppen – das war der zweite Teil des Fehlers.
await worker.StopAsync(CancellationToken.None);
worker.Info.Status.Should().Be(WorkerStatus.Stopped);
}
/// <summary>
/// "Letzter Lauf" muss auch nach einem Fehlschlag stehen: sonst ist ein Worker, der seit Tagen
/// bei jedem Versuch scheitert, in der Tabelle nicht von einem zu unterscheiden, der noch nie
/// gelaufen ist.
/// </summary>
[Fact]
public async Task FailedRun_StillRecordsLastRuntime()
{
var worker = new TestWorker(interval: null,
_ => throw new InvalidOperationException("boom"));
await worker.StartAsync(CancellationToken.None);
await WaitUntilAsync(() => worker.Info.Status == WorkerStatus.Error, "Status wird Error");
worker.Info.LastRuntime.Should().NotBeNull();
await worker.StopAsync(CancellationToken.None);
}
}