Sollte ich unit test Methoden, die vererbt werden, von der super-Klasse?

Schreibe ich momentan eine Implementierung der JDBC-Treiber (ja, Sie haben richtig gelesen) in TDD-Manier, und zwar habe ich nur fertige Klasse stubs an diesem Punkt, und nur einige kleinere Funktionen, nur es fiel mir auf, daß da Statement ist eine Superklasse für PreparedStatement das ist eine Superklasse für CallableStatement, was soll ich tun, wenn ich wirklich anfangen zu schreiben, tests für meine Implementierungen dieser Klassen, welche von diesen soll ich tun:

  1. Erstellen einer test-suite für Statement und dann erweitern, die suite für zusätzliche tests für PreparedStatement und dann das gleiche tun für CallableStatement.
  2. Test in jeder Implementierung individuell ignorieren der geerbten Methoden aus der Superklasse(N).
  3. Gründlich zu testen jeder einzelnen Methode individuell für jede Implementierung der Klasse; Es ist möglich, dass einige ererbte Methoden funktionieren anders, je nach Umsetzung, nachdem alle. Milde Variante wäre, dass ich würde testen alle diejenigen, die geerbten Methoden der Implementierung verwendet.

Nummer zwei fühlt die natürlichen aber aus dem Grund lege ich die Dritte bin ich nicht sicher, ob es wäre klug, dies zu tun. Also, was tun Sie denke, dass ich tun soll?

InformationsquelleAutor Esko | 2009-01-01
  1. 7

    Ich möchte ausdrücklich nie tun alternative 1 (lassen sich die test-Klassen-Hierarchie werden die gleichen wie die eigentlichen Klassen-Hierarchie) wenn dies bedeutet, dass Sie die gleichen tests wiederholt für jede test-Unterklasse. Ich bin auch generell skeptisch Unterklassen test anderen Klassen als die Allgemeine Nützlichkeit Basisklasse.

    Ich normalerweise 1-test für jede Klasse in einer Hierarchie, Abstrakt oder nicht. Also die Basisklasse hat einen separaten test (in der Regel mit einem test-lokale private Unterklasse, die verwendet wird, um es zu testen um genau zu sein), und ich nutze mein wissen um die Unterklassen zu schreiben, die richtigen tests für jede Unterklasse. Ich kann sehen, dass in der Abdeckung läuft, was fehlt, tests, also ich bin in der Regel nicht zu formalisiert up-front.

    InformationsquelleAutor krosenvold
  2. 11

    "testen Sie jede einzelne Methode individuell für jede Implementierung der Klasse"

    Insbesondere, Fehler zu überschreiben einer superclass-Methode richtig ist ein allgemeiner Fehler. Der Autor der Unterklasse Annahmen über die Oberklasse. Die Oberklasse ändert, und die Unterklasse ist nun gebrochen.

    • Dies wäre der richtige Weg, es zu tun. Sie müssen sicherstellen, dass alle Methoden funktionieren immer noch.
    • Nehme an, dass ich Superklasse A - und Unterklassen B und C. A hat Methode a() die weder B noch C haben, überschrieben. Du sagst, dass, dennoch, meine tests testen müssen A.a(), B.a(), C.a() ist, obwohl er die Prüfung der exakt gleichen Methode (weder B noch C außer Kraft setzen, nur vererben) 3 verschiedene Zeiten?? Vergessen Sie TROCKEN, wenn Tests, die ich denke,
    InformationsquelleAutor S.Lott
  3. 4

    Genügend tests, so dass Sie sich wohl fühlen - auf der Grundlage Ihrer Kenntnisse der Umsetzung. Ich nicht behandeln, unit-Tests als komplett black-box-Tests. Wenn Sie wissen, dass die Basisklasse ruft nie alle virtuellen Methoden (oder zumindest keine, die überschrieben werden), dann beachten Sie, dass der Tat, aber nicht effektiv duplizieren Sie die unit-tests, die Sie schon haben.

    Unit-Tests kann sicherlich auf die Spitze getrieben - es lohnt sich immer, den Ausgleich der Wert, Sie bekommen von es mit die Anstrengung, die es Sie kostet.

    InformationsquelleAutor Jon Skeet
  4. 1

    Mit TDD, sollten Sie nicht wollen, zu Methoden der Prüfung, sondern das Verhalten oder den Fähigkeiten Ihres Codes. Deshalb ist bei der Implementierung einer Unterklasse, die Sie einschränken können, um die Prüfung nur die Verhaltensweisen, die unterschiedlich sind von der Basisklasse. Wenn Sie Zweifel haben, schreiben Sie einen neuen test.

    InformationsquelleAutor philant
Schreibe einen Kommentar