Unittests generieren ?

[Ghostwalker]

Moinsen,

Ich habe einige Typen erstellt, die untereinander verrechnet und bearbeitet werden können (Maßeinheiten). Pro Typ gibts ca. 11 Operatoren + entsprechende Operatoren mit den anderen Typen verknüpft.

Wenn ich jetzt für jede Operator/Typ Kombination eine eigene Testmethode bau, bin ich bis zur Rente voll ausgelastet (7/24 gerechnet).

Deshalb die Frage: Gibts eine Möglichkeit sowas zu generieren ? oder hat jemand eine Idee, wie man das ganze vereinfachen kann ?

[Wosi]

Generierte Tests liefern in den allerseltensten Fällen einen Mehrwert.
Hast du Beispiele für die Typen + Operatoren? Wie kann ich mir das vorstellen?

[Stevie]

Ja, das Prinzip nennt sich data-driven unit testing.

[Ghostwalker]

@Wosi

Ok....ein wenig mehr Beispiele

Basistyp "Gramm"

Delphi-Quellcode:

Type
  Gramm = record
  private
    fvalue : integer
  public
     Class Operator Implicit(const avalue:gramm):integer;
     Class Operator Implicit(const avalue:integer):gramm;
      :
      :
     Class Operator Add(const left:gramm;right:integer):gramm;
     Class Operator Add(const left:integer;right:gramm):gramm;
      :
      :

Delphi-Quellcode:

Type
  Kilogram = record
   :
   :
  Class Operator Add(const left:kilogram;const right:integer):kilogram;
  Class Operator Add(const left:kilogram;const right:gramm):gramm;
  :

Damit ist dann folgendes möglich:

Delphi-Quellcode:

:
:
var
  g,eg : gramm;
  kg: kilogram;
  v : integer;

begin
  g := 150; //150 Gramm
  kg := 10; //10 Kilogram
  eg := g+kg; //Ergibt 1150 gramm
end;

Neben den Implicit und Explicit operatoren gibts, Add, Subtract, Multiply, IntDiv, Modulus, >, <, =, <>, >=, <=

Also ne ganze Ecke.

Wenn ich hier also jeden Operator mit jeder Typkombination in einer eigenen Methode testen möchte, schreibt man verdammt viel Quelltext (sprich bis ich das hab, geh ich in Rente).

@Stevie

Darüber bin ich auch schon gestolpert, hab mich aber nicht wirklich damit befasst. Muss ich mal guggen

[Wosi]

Ich habe das Gefühl, du schaffst dir mit den einzelnen Record-Typen für jede Maßeinheit mehr Arbeit als alles andere und produzierst dadurch eine menge doppelten Code. Welchen Vorteil erhoffst du dir durch die Typen?
Wäre es nicht einfacher, intern alle Gewichtswerte in Gramm vorliegen zu haben? Rechen- und Vergleichsoperationen gibt es dann gratis.

[Ghostwalker]

Die Gewichte waren hier nur ein Beispiel (oder eine Analogie).

Die Typen dienen als Basis für div. andere Typen und Klassen, die damit arbeiten.

Da ich die letztliche Zielanwendung nicht kenne, muss ich den größt Möglichen Bereich abdecken. D.h. z.B.
vom einfachen Rezept bis hin zur Tonagenberechnung für Containerschiffe sollte alles möglich sein.

Und...2000t in Gramm sprengt so ziemlich jeden normalen Typ

[Wosi]

Integer kommt bis ~2.100t, Cardinal bis ~4.300t und Int64 bis ~9,2Gt

Mein Punkt ist im Kern: Ich denke du machst dir unnötig viel Arbeit, wenn du Umrechnungen von jedem Typ in jeden anderen manuell herunterschreibst. Such dir ein geeignetes Zwischenformat, in das du jeden Wert konvertierst, bevor du Vergleiche und Rechenoperationen durchführst. Das wird dir viel Schreibarbeit und viel Fehlerpotenzial ersparen. In meinem Beispiel war das Zwischenformat Gramm.

Evtl. ist es auch sinnvoll, einen Record mit Wert und Umrechnungsfaktor zu verwenden. Dadurch könntest du enorm große Zahlen vermeiden. Beispiel:

Delphi-Quellcode:

  TWeightValue = record
    Value: Integer;
    Factor: Integer;
  end;

  // ...
  var
    CarWeight, ContainerShipWeight, LoadedContainerShipWeight: TWeightValue;
  begin
    CarWeight.Value := 1500;
    CarWeight.Factor := 1000; // value in kg

    ContainerShipWeight.Value := 2000;
    ContainerShipWeight.Factor := 1000*1000; // value in tonnen

    LoadedContainerShipWeight:= ContainerShipWeight + (CarWeight * 500); // Schiff ist mit 500 Autos voll beladen

    Assert(LoadedContainerShipWeight.Value, 2750);
    Assert(LoadedContainerShipWeight.Factor , 1000*1000);
  end;

In dem Fall bräuchtest du nur einen Record-Typen und müsstest nur jeweils einen Operatoren für die Verwendung mit einem anderen TWeightValue und einem Integer schreiben. Das lässt sich dann auch deutlich einfacher testen.

[TigerLilly]

Mir kommt das auch sehr aufwändig vor. Wir haben das so gelöst:
Tabelle mit Attributen (Einheit, nächst kleinere Einheit+Faktor, nächst größere Einheit+Faktor, Typ der Einheit)

Beispiel:

kg, g, 0.001, t, 1000, Gewicht
g, mg, 0.001, kg, 1000, Gewicht

Das geht für Volumen+Zeit etc gleichermaßen.


Will man eine Einheit in andere umrechnen, hangelt man sich der Kette entlang. Wenn man lustig ist, kann beim Rechnen je nach notwendiger Genauigkeit die Einheiten wechseln.

[Ghostwalker]

Bitte zurück zum Thema.

[hoika]

Hallo,
willst Du eine bestmögliche Testabdeckung, bleibt dir nichts anderes übrig,
also bis zur Rente Tests zu schreiben.

1. Oder Du definierst dir eine minimal Testabdeckung von z.B. 50% und musst damit leben,
dass dir eventuell was hinten runterfällt.

2. Oder du definierst Dir Tests mit den Funktionen/Zugehörigkeiten die Du im Moment benutzt.
Ergebnis: wie 1.


Ich glaube nicht, dass es Programme gibt, die dir die Tests selber generieren.

Zur Vereinfachung: BigInt nehmen als gemeinsame Datenbasis (rechnet theoretisch alles aus, egal wie groß die Werte sind)