Unittest - Kopieren einer Klasse

[SProske]

Hallo allerseits,
wir haben hier einige Datenhaltungsklassen, die zusätzlich noch eine Methode zum kopieren des Objektinhalts haben, im einfachsten Falle so:

Delphi-Quellcode:

  TFoo = class
  strict protected
    FBar: Integer;
  public
    property Bar: Integer read FBar write FBar;
    procedure Assign(const Source: TFoo);
  end;

procedure TFoo.Assign(const Source: TFoo);
begin
  self.FBar := Source.Bar;
end;

Wie geht man hier das Thema Unittesting am besten an?

- Gar nicht testen?
- Im Test prüfen, dass Bar korrekt gesetzt ist - sollte irgendwann eine neue Property hinzukommen, muss man daran denken, dafür einen neuen Unittest zu schreiben - bis dahin laufen die Unittests durch, auch wenn die neue Property nicht korrekt gesetzt wird
- Im Test prüfen, dass alle Properties korrekt gesetzt sind, also auch derzeit noch nicht bekannte (wie??)
- Irgendwie ganz anders?

Das verwendete Framework ist DUnit, Delphiversion ist XE3.

[Der schöne Günther]

TFoo die function Equals(const other: TFoo): Boolean hinzufügen, Tests dafür schreiben. Der Test ob Assign funktioniert beschränkt sich dann ob nach einem Assign(..) dann Equals(..) True zurück liefert.

Zitat:

Im Test prüfen, dass alle Properties korrekt gesetzt sind, also auch derzeit noch nicht bekannte (wie??)

Man könnte z.B. mittels RTTI über alle Felder gehen und mittels Default-Comparer vergleichen. Ich finde das zu unsicher und den Aufwand nicht wert. Wenn ich an einer Klasse herumdoktere muss ich dafür akzeptieren auch die Erwartungen (den Unit-Test) nochmal anschauen zu müssen. Die Assign-Methode (und ähnliches) muss man dann ja sowieso anpassen wenn man z.B. ein neues Feld hinzufügt.

Mein Weltbild ist manchmal schockierend simpel.

[Sir Rufo]

Zitat von Der schöne Günther:

TFoo die function Equals(const other: TFoo): Boolean hinzufügen, Tests dafür schreiben. Der Test ob Assign funktioniert beschränkt sich dann ob nach einem Assign(..) dann Equals(..) True zurück liefert.

Mein Weltbild ist manchmal schockierend simpel.

Dann hast du nur geprüft ob nach einem Assign Equals wie erwartet true zurückliefert. Mehr nicht.

War das so gewollt?

Über RTTI würde ich keinen Vergleich machen, wohl aber die Eigenschaftsnamen abfragen und mit denen vergleichen, die im Test berücksichtigt werden. Dann gibt es eine Meldung darüber und man kann den Test anpassen.

[Der schöne Günther]

Zitat von Sir Rufo:

War das so gewollt?

Ja, denn meinem Test für Equals(..) muss ich vertrauen. Wenn man unter Assign() jetzt etwas anderes versteht als die "subjektive Gleichheit" dann passt das natürlich nicht. Wie gesagt, in meinem simplen Weltbild ist das so.

Interne Caches wären jetzt etwas das ich bspw. weder mit Assign() übertragen würde, noch mich bei einer Gleichheit wie Equals() interessieren würde.

[Uwe Raabe]

Zitat von SProske:

sollte irgendwann eine neue Property hinzukommen, muss man daran denken, dafür einen neuen Unittest zu schreiben

Das hinter den Unittests stehende Paradigma besagt ja auch, daß du den Unittest schreiben musst, bevor das neue Property dazu kommt. Damit der dann compiliert musst du das property und gegebenfalls das dahinter liegende Feld auch in der Klasse einführen. In dem Moment läuft der Test, schlägt aber fehl bis das Assign angepasst wurde. Wenn du dich an diese Reihenfolge hältst, kann eigentlich nichts schief gehen.

Ich habe so meine Bedenken bei sich selbst anpassenden Tests.

[Stevie]

Zitat von Uwe Raabe:

Das hinter den Unittests stehende Paradigma besagt ja auch, daß du den Unittest schreiben musst, bevor das neue Property dazu kommt.

Du spielst auf TDD an. Kann ich nur empfehlen, obwohl ich auch schuldig bin, das nicht immer zu praktizieren.
Aber schlussendlich führt es zu besserem Code, da man sich in aller Regel vorher Gedanken macht (da man ja den Test schreiben muss), sowohl über die API als auch über die Implementierung.

Testen von Methode A durch Aufrufen von Methode B halte ich für ziemlich fehleranfällig.

[Uwe Raabe]

Zitat von Stevie:

Kann ich nur empfehlen, obwohl ich auch schuldig bin, das nicht immer zu praktizieren.

Ich glaube kaum, daß hier irgendjemand im biblischen Sinne den ersten Stein werfen könnte.