Single-Source-Unit-Tests für Free Pascal und Delphi

8

Gibt es eine Möglichkeit, Komponententests zu schreiben, so dass sie sowohl mit Delphi als auch mit Free Pascal kompiliert und ausgeführt werden können?

Es gibt verschiedene Unit-Test-Frameworks für Delphi und Free Pascal, die für Entwickler, die auf beide Compiler (z. B. Bibliotheks- und Framework-Entwickler) abzielen, doppelte Arbeit verursachen.

Vielleicht gibt es also einen Weg, entweder das DUnit- oder das FPCUnit-Framework zu verwenden und den Testfall-Quellcode (oder das Framework selbst) so zu optimieren, dass er auch mit dem anderen Compiler funktioniert.

Also im Wesentlichen die Frage ist:

  • welches Framework (DUnit oder FPCUnit) kann mit beiden Compilern (Delphi und Free Pascal) mit so wenig Modifikationen wie möglich kompiliert werden?

oder

  • gibt es einen dritten Rahmen (Danke an Arnaud für die Erwähnung von TSynTest), der mit Delphi und FPC funktioniert?
mjn 30.08.2012, 19:38
quelle

3 Antworten

6

Das Standard-Unit-Test-Framework für Free Pascal ist FPCUnit, es hat das gleiche Design wie DUnit, unterscheidet sich aber in kleinen Details davon. Sie können allgemeine Komponententests für FPCUnit und DUnit schreiben, indem Sie die Unterschiede nach {$IFDEF FPC} umgehen. Ich habe gerade FPCUnit getestet, es ist ein brauchbares Framework und bloggte darüber .

    
kludg 31.08.2012, 06:25
quelle
10

Siehe sehr schönen Blog-Artikel - nur frisches Fleisch über FPCUnit Tests.

Kurz gesagt, soweit ich weiß, und wenn Sie mit DUnit vergleichen :

  • Die meisten Check * () -Methoden wurden in Assert * ();
    • umbenannt
  • SetUp / TearDown-Methoden heißen per-function in beiden Frameworks;
  • Einige andere Gedanken können variieren.

Also, ich denke, es könnte leicht sein, FPCUnit "imitieren" DUnit, durch Erstellen einer kleinen Wrapper-Klasse über FPCUnit-Implementierung, um die gleichen Methoden als mit DUnit zu haben. Daher können Sie möglicherweise Code zwischen den beiden Zielen austauschen und sogar vorhandene DUnit-Tests erneut verwenden. Eine solche Wrapperklasse ist IMHO viel bequemer als {$ifdef FPC} , wie hier vorgeschlagen. Bedingte Kompilierung neigt dazu, Code schwer zu debuggen, ausführlich, redundant und sollte nur bei Bedarf verwendet werden.

Eine andere mögliche Lösung könnte die Verwendung anderer Test-Frameworks sein. Unsere kleinen TSynTest-Klassen sind leichter, aber ich bin gerade dabei Konvertieren des Frameworks in FPC. Also könnte derselbe genaue Code mit beiden Compilern verwendet werden. Es hat einige Funktionen (wie optionale Protokollierung mit Feinprofilierung und Vollstackstrace bei Ausfall), die ich von DUnit / FPCUnit vermissen würde. Es hat keine GUI oder einen Wizard, aber ehrlich gesagt, da ich Programmierer bin, bevorzuge ich Klartext, den ich leicht in meine technische Release-Dokumentation aufnehmen kann, um zu bestätigen, dass keine Regression stattgefunden hat.

    
Arnaud Bouchez 31.08.2012 06:34
quelle
3

Ich habe gerade ein Beispiel aufgepeitscht, das sowohl in DUnit (Delphi) als auch in FPCUnit (Freepascal-Äquivalent zu DUnit, das in "lazarus 1.0", das Freepascal 2.6 enthält) bereits "in der Box" enthält:

Ein triviales Stück IFDEF und du bist da.

%Vor%     
Warren P 31.08.2012 01:45
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Testen, ob sich mehrere Objekte in einer Liste befinden, die eine "in" -Anweisung (Python) verwenden [duplizieren]