Soll ich Unit-Test-Methoden, die aus Superklasse geerbt?

Question

Ich bin derzeit eine Implementierung eines JDBC-Treiber zu schreiben ( Ja, Sie lesen richtig, dass ) in einer TDD-Weise und während ich an dieser Stelle nur fertige Klasse Anschlussabzweigungen und nur einige kleinere Funktionalität, es trat nur mir, dass seit Statement eine übergeordnete Klasse für PreparedStatement, die eine übergeordnete Klasse für CallableStatement ist, was soll ich tun, wenn ich Tests zu schreiben beginnen, um wirklich für meine Implementierungen dieser Klassen, die eine davon soll ich tun:

1. eine Testsuite für Statement erstellen und dann diese Suite für zusätzliche Tests für PreparedStatement erweitern und dann das Gleiche tun für CallableStatement.
2. Test jeweils einzeln Implementierung der Methoden geerbt von übergeordneter Klasse zu ignorieren (es).
3. testen Sie strengstens jede einzelne Methode individuell für jede Implementierungsklasse; Es ist möglich, dass einige geerbte Methoden anders arbeiten, nachdem alle über die Umsetzung abhängig. Mild Variante wäre, dass ich all diese geerbten Methoden testen würde die Implementierung verwendet.

Nummer zwei fühlt sich die natürlichste, aber aus dem Grund habe ich auf die dritte, die ich nicht so sicher bin, ob es klug wäre, dies zu tun. Also, was tun Sie denke ich tun sollte?

Answer 1

würde ich speziell nie tun Alternative 1 (lassen Sie den Test-Klassenhierarchie die gleiche wie die tatsächliche Klassenhierarchie sein), wenn dies bedeutet, dass Sie die gleichen Tests wiederholt für jede Testunterklasse ausgeführt werden. Ich bin auch generell skeptisch Subklassen Testklassen anders als die allgemeine Nützlichkeit Basisklasse.

Ich mache normalerweise 1-Test für jede Klasse in einer Hierarchie, abstrakt oder nicht. So ist die Basisklasse hat einen separaten Test (in der Regel mit einer Test-lokaler Privatunterklasse, die zum Testen es speziell verwendet wird), und ich meine Kenntnisse über die Unterklassen für jede Unterklasse richtige Tests zu schreiben. Ich kann sehen, in Deckung läuft, was fehlt Tests ist, so dass ich in der Regel nicht zu formalisiert up-front.

Answer 2

„testet jede einzelne Methode individuell für jede Implementierungsklasse“

Insbesondere Versagen eine übergeordnete Klasse Methode außer Kraft zu setzen ist richtig ein gemeinsamer Fehler. Der Autor der Unterklasse macht Annahmen über die übergeordnete Klasse. Die übergeordnete Klasse ändert, und die Unterklasse ist nun gebrochen.

Answer 3

genug Tests, so dass Sie sich wohl fühlen - basierend auf dem Wissen über die Umsetzung. Ich weiß nicht Unit-Tests als völlig schwarz-Box-Test behandeln. Wenn Sie, dass die Basisklasse kann nie wissen alle virtuelle Methoden aufruft (oder zumindest keine, die überschrieben werden), dann beachten Sie, dass dadurch aber nicht effektiv die Unit-Tests duplizieren, die Sie schon haben.

Unit-Tests kann sicherlich auf die Spitze getrieben werden. - es lohnt sich immer, den Wert Ausgleich Sie aus es mit dem Aufwand bekommen Sie es kostet

Answer 4

Mit TDD, sollten Sie nicht auf Testmethoden zielen darauf ab, sondern Verhalten oder Fähigkeiten Ihres Codes. Daher kann, wenn eine Unterklasse der Umsetzung, können Sie nur das Verhalten zu testen beschränken, die von der Basisklasse unterschiedlich sind. Wenn Sie Zweifel haben, schreiben Sie einen neuen Test.