Wie schreiben Sie Tests für Code, der den zu testenden Code dupliziert?

Question

Ich arbeite daran, so viel Logik wie möglich aus einem benutzerdefinierten Steuerelement zu verschieben, so dass es Einheit getestet werden kann, um den manuellen Testaufwand zu reduzieren. Ich habe Probleme mit Situationen, in denen eine zu testende Methode ein komplexes Ergebnis liefert. Das Schreiben eines Testfalls, der das Ergebnis berechnet, würde beinhalten, was im Wesentlichen der getestete Code ist, in den Test selbst zu schreiben.

Zum Beispiel habe ich eine GeometryGenerator Klasse, die eine WPF-Geometrie basierend auf den Eigenschaften der Klasse erstellt. In einer Konfiguration wird ein PathGeometry generiert, der aus einem ArcSegment besteht. Ich kann berechnen, wie die Eigenschaften des Bogens auf den Testparametern basieren sollten, aber diese Berechnung ist identisch mit dem Code, den ich versuche zu testen. Dies scheint den Test unwirksam zu machen; Wenn es einen Fehler in der Berechnung gibt, liegt ein Fehler im Test vor, und wenn sich die Berechnung in der Methode ändert, muss sie möglicherweise im Test geändert werden.

Was mache ich in dieser Situation? Der einzige Ansatz, den ich mir vorgenommen habe, ist, die Ergebnisse meiner Testfälle manuell zu berechnen und diese Werte fest in die Tests zu codieren. Ist das ein akzeptabler Ansatz (es scheint so, als hätte ich die Tests vor der Implementierung geschrieben)?

Answer 1

Der einzige Ansatz, den ich habe, ist, die Ergebnisse meiner Testfälle manuell zu berechnen und diese Werte fest in die Tests zu codieren. Ist das ein akzeptabler Ansatz (es scheint so, als hätte ich die Tests vor der Implementierung geschrieben)?

Ja, das ist typisch. Für den Unit-Test müssen Sie davon ausgehen, dass die Formel, die Sie zur Berechnung Ihrer Ergebnisse verwenden, korrekt ist. Es ist die Software-Implementierung, die Sie testen.

Sie berechnen einige manuell berechnete Ergebnisse vorab, um sicherzustellen, dass Sie den zu testenden Code nicht zur Generierung der Testdaten verwenden (eine sehr schlechte Sünde beim Komponententest). Stellen Sie sicher, dass Sie Ihre Testfälle dokumentieren, damit Sie wissen, was die erwarteten Werte darstellen und woher sie kommen.

Answer 2

Ein "Komponententest" sollte wirklich nur ein einzelnes Gerät testen. So ideal würden Sie separate Unit-Tests für Ihre GeometryGenerator haben, eine andere für Ihre PathGeometry Klasse, ein Drittel für Ihre ArcSegment usw.

Durch separat jede der Einheiten testen, können Sie irgendeine Art von Vertrauen gewinnen, wie sie sich verhalten wenn Sie bestimmte Operationen für sie mit einer gegebenen Menge von Eingängen aufrufen (wie verhält sich das GeometryGenerator, wenn ein Feld in ArcSegment auf 1 gesetzt ist, vs. wie es sich verhält, wenn das gleiche Feld auf 0 gesetzt ist, usw.).

Wenn Ihr Komponententest so aussieht, als würden Sie vorhandenen Code duplizieren, um eine bestimmte Funktionalität zu testen, dann haben Sie Angst, dass Sie Unit-Tests falsch durchführen und dass es eine einfachere und effektivere Lösung für Sie gibt .

Answer 3

Handberechnung und Festcodierung sind schlecht im Produktionscode, aber wichtig für gute Komponententests.

Normalerweise möchten Sie einen Test für jeden "Zustand" des Codes schreiben. Zum Beispiel schreibe ich oft Tests mit positiver Eingabe, negativer Eingabe und Nulleingabe, um sicherzustellen, dass der Code wie erwartet funktioniert.

Answer 4

Normalerweise werde ich eine magische Zahl machen, dass die Selbst Dokumente aber hartcodiert ist, wie

const int expectedResult = 2 * 4/someConstant; // vielleicht ein Kommentar.

Der Leser des Tests kann ableiten, was die Werte sind, oder Sie können bei Bedarf zusätzliche Kommentare hinzufügen.