Unittests generieren ?

[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)

[TigerLilly]

Schreib dir einen Testgenerator, der den Code für die Tests erzeugt. Du hast jetzt ja eh schon jede Menge Boilerplate-Code. Bzw lass deine Klassen gleich den Code für die Tests erzeugen.

Oder: Deine Klassen sollen ihren Typ + ihre Operatoren in einer Liste registrieren. Aus dieser Liste erzeugst du dann (halbautomatisch) die Testfälle.

Off-topic: Wenn es so aufwändig ist, Testfälle zu schreiben, hapert´s am Design.