Unittest von OnWhatever Events?

[Sir Rufo]

Zitat von Dejan Vu:

Beides, oder?

1. Teste den Thread, das er das macht, was er machen soll (z.B. die Objektmethode aufrufen, die einen Event feuern soll. Ob der gefeuert wird, interessiert den Thread ja nicht).
2. Teste das Objekt, das den Event feuert, wenn es soll.

Ich hätte es jetzt nicht schöner sagen können.

Beim Unittest darf man eben nie aus den Augen verlieren, was man testen möchte. Manchmal benötigt man auch ein paar Dummies zum Testen, denn wer will schon beim Testen einer SEPA-Schnittstelle aus Versehen 100000,00€ überweisen oder per Lastschrift einziehen.

[Stevie]

Hatte vor einiger Zeit schonmal was in DSharp für async/await in Delphi zusammen gebaut, was mir hier in abgewandelter Form nützlich erschien:

Delphi-Quellcode:

unit Unit1;

interface

uses
  MyDings,
  SyncObjs,
  TestFramework;

type
  TDingsTest = class(TTestCase)
  private
    fSUT: TMyDings;
    fInitDoneEvent: TEvent;
    procedure HandleInitDone(Sender: TObject);
  protected
    procedure SetUp; override;
    procedure TearDown; override;
  published
    procedure OnInitDone_Is_Fired_Within_Ten_Seconds_After_Calling_Init;
  end;

implementation

uses
  Classes,
  Diagnostics,
  Forms,
  Math,
  Windows;

function WaitFor(handle: THandle; timeout: Cardinal): TWaitResult;
var
  handles: array[0..1] of THandle;
  stopwatch: TStopwatch;
begin
  if GetCurrentThreadId = MainThreadID then
  begin
    handles[0] := handle;
    handles[1] := SyncEvent;
    stopwatch := TStopwatch.StartNew;
    repeat
      case MsgWaitForMultipleObjects(2, handles, False, IfThen(timeout = INFINITE,
        INFINITE, timeout - stopwatch.ElapsedMilliseconds), QS_ALLINPUT) of
        WAIT_OBJECT_0: Exit(wrSignaled);
        WAIT_OBJECT_0 + 1: CheckSynchronize;
        WAIT_OBJECT_0 + 2: Application.ProcessMessages;
        WAIT_ABANDONED: Exit(wrAbandoned);
        WAIT_FAILED: Exit(wrError);
      end;
    until stopwatch.ElapsedMilliseconds >= timeout;
    Result := wrTimeout;
  end
  else
    case WaitForSingleObject(handle, timeout) of
      WAIT_OBJECT_0: Result := wrSignaled;
      WAIT_ABANDONED: Result := wrAbandoned;
      WAIT_TIMEOUT: Result := wrTimeout;
    else
      Result := wrError;
    end;
end;

{ TDingsTest }

procedure TDingsTest.HandleInitDone(Sender: TObject);
begin
  fInitDoneEvent.SetEvent;
end;

procedure TDingsTest.OnInitDone_Is_Fired_Within_Ten_Seconds_After_Calling_Init;
begin
  fSUT.Init;
  CheckTrue(WaitFor(fInitDoneEvent.Handle, 10000) = wrSignaled);
end;

procedure TDingsTest.Setup;
begin
  fSUT := TMyDings.Create;
  fSUT.OnInitDone := HandleInitDone;
  fInitDoneEvent := TEvent.Create;
end;

procedure TDingsTest.Teardown;
begin
  fInitDoneEvent.Free;
  fSUT.Free;
end;

initialization
  RegisterTest(TDingsTest.Suite);

end.

[Mavarik]

Ja das sieht gut aus, Danke!

Muss mir nur noch überlegen, wie und ob ich den produktiven Teil des Init abkoppele oder mit testen soll...
Ich möchte ja ggf. nicht nur die Funktionalität der Procedure Testen, sondern ggf. auf die Daten die hinten raus kommen.
Vielleicht muss ich da noch ein Dummy-Interface mit übergeben, welches die Routinen von der aktiven Datenbank auf ein Testmodel umlenkt..
(Siehe SEPA Beispiel)
Jeremy North hatte da so ein schönes Kreditkartenbeispiel...

Aber ich denke so komme ich erst mal weiter...

Mavarik

[Mavarik]

Gibt es eine "elegante" Möglichkeit innerhalb des Testforms an zu zeigen, das ein Test noch läuft und nicht abgestürzt ist?

Mavarik

[Stevie]

Zitat von Mavarik:

Gibt es eine "elegante" Möglichkeit innerhalb des Testforms an zu zeigen, das ein Test noch läuft und nicht abgestürzt ist?

Was ist abgestürzt? Durch die Threadinggeschichte in nen Deadlock gelaufen? Schwierig.
Alles andere würd ja irgendwie entweder das Timeout signalisieren oder ne Exception werfen.

[Mavarik]

Zitat von Stevie:

Was ist abgestürzt? Durch die Threadinggeschichte in nen Deadlock gelaufen? Schwierig.
Alles andere würd ja irgendwie entweder das Timeout signalisieren oder ne Exception werfen.

ne ne ist nix abgestürzt. Ich dache es gibt so etwas wie eine Sanduhr oder ein Processbar für den einzelnen Test.
kann natürlich ein Fester aufmachen... Bitte warten...

Nicht alle Testroutinen sind in 2 Sekunden fertig... Was ist wenn ein Test 2 Minuten dauert?

Mavarik

[Stevie]

Zitat von Mavarik:

Ich dache es gibt so etwas wie eine Sanduhr oder ein Processbar für den einzelnen Test.
kann natürlich ein Fester aufmachen... Bitte warten...

Nicht alle Testroutinen sind in 2 Sekunden fertig... Was ist wenn ein Test 2 Minuten dauert?

Naja, Sanduhr setzen is ja simpel.
In Bezug auf die Zeit muss man sagen, direkte Unittests sollten so geschrieben werden, dass sie sehr schnell durchlaufen (gerade wenn man TDD macht).
Aber mit DUnit kann man ja nicht nur Unittests sondern auch Integrationstest durchführen, die durchaus ihre Zeit in Anspruch nehmen können.

Das wäre aber wohl dann was, was man in den DUnit GUIRunner einbauen könnte.