Unit testen von Timer gesteuerem Code

[Der schöne Günther]

Du hast dir doch die Erklärung schon selbst gegeben:

Zitat von TurboMagic:

dann kommt
das Finalization der Log-Klassen Unit mit Freigabe des Log-Objektes vor der Freigabe des
Interfaces!

DUnit wird wohl so funktionieren dass bis zum bitteren Ende eine Instanz deiner Testklasse vorliegt, und da zeigt die Referenz halt noch auf dein IGedöns .

Ich würde

1. Diese Log-Meldung im Destruktor optional/abschaltbar machen. Hier scheinst du sie ja auch nicht zu brauchen
2. Das meinGedöns := nil im TearDown() drin lassen. Ich könnte mich irren, aber ich meine das brauchst du auch insbesondere, wenn du mit deinen Unit-Tests Speicherlecks finden willst, da vergleicht er ja im Endeffekt auch nur "Vor SetUp()" mit "nach TearDown()" und wenn am Schluss mehr da ist als vorher war, dann ist es ein Speicherleck.

[Mavarik]

Wie Günter schon geschrieben hat. Ein TimeService ist immer hilfreich.
Man kann auch einen normalen Event nehmen ohne Spring und nutzt den WaifFor(TimeOut) davon, so
kann man zwei Fälle abdecken. 1.) Event is gekommen oder 2. TimeOut.
Ich gebe dann gerne eine Procedure mit, das sieht dann so aus:

Delphi-Quellcode:

var
  WasCalled : boolean;
  E         : TEvent;
  R         : TWaitResult; 
begin
  WasCalled := false;

  E := DoSomeTing(Procedure
    begin
      WasCalled := true;
    end);

  R := E.WaitFor(5000);

  if R = wrSignaled 
    then Assert.IsTrue(WasCalled)
    else Assert.Fail('TimeOut'); // or error

  E.Free;
end;

Ich hoffe ich hab Dich richtig verstanden...

[TurboMagic]

Hallo,

ich hab' mir jetzt einen Timer mit Interface drumherum gebaut.
Der hat das Enable gewrappt und ein zusätzliches Flag für den Unit Test.
Damit lege ich fest, ob OnTimer des Timers über den Timer kommen soll
(regulärer Betrieb) oder wenn eine bestimmte "Operation ist zuende"
Methode aufgerufen wird (Unit Test Betrieb), die im normalen Betrieb
einfach nichts tut.

Funktioniert für mich.

Grüße und Danke
TurboMagic