Ich schreibe gerade eine Implementierung eines JDBC-Treibers ( ja, Sie haben das richtig gelesen ) in TDD-Manier, und während ich an dieser Stelle nur Klassen-Stubs beendet habe und nur ein paar kleinere Funktionen, Es ist mir gerade aufgefallen, dass Statement eine Oberklasse für PreparedStatement ist, was eine Oberklasse für CallableStatement ist, was soll ich tun, wenn ich wirklich anfange, Tests für meine Implementierungen dieser Klassen zu schreiben, welche davon sollte ich tu:
Statement und erweitern Sie diese Suite dann um weitere Tests für PreparedStatement und machen Sie dasselbe für CallableStatement . Nummer zwei fühlt sich am natürlichsten an, aber aus dem Grund, den ich dem dritten gegeben habe, bin ich mir nicht sicher, ob es vernünftig wäre. Also, was denkst du sollte ich tun?
Ich würde insbesondere niemals die Alternative 1 (die Testklassenhierarchie wäre mit der tatsächlichen Klassenhierarchie identisch) ausführen, wenn dies bedeutet, dass Sie für jede Testunterklasse wiederholt die gleichen Tests durchführen. Ich bin auch generell skeptisch, andere Testklassen als die allgemeine Utility-Basisklasse zu bilden.
Ich mache normalerweise 1 Test für jede Klasse in einer Hierarchie, abstrakt oder nicht. Also hat die Basisklasse einen separaten Test (normalerweise mit einer testlokalen privaten Unterklasse, die speziell für den Test verwendet wird), und ich benutze mein Wissen über die Unterklassen, um die richtigen Tests für jede Unterklasse zu schreiben. Ich kann in Coverage-Läufen sehen, welche Tests fehlen, daher bin ich normalerweise nicht zu formalisiert.
"Testen Sie jede einzelne Methode für jede Implementierungsklasse einzeln"
Insbesondere ist der Fehler, eine Superklassenmethode richtig zu überschreiben, ein häufiger Fehler. Der Autor der Unterklasse macht Annahmen über die Oberklasse. Die Oberklasse ändert sich und die Unterklasse ist jetzt unterbrochen.
Stellen Sie genügend Tests zur Verfügung, damit Sie sich wohl fühlen - basierend auf Ihrem Wissen über die Implementierung. Ich behandle Komponententests nicht als vollständige Black-Box-Tests. Wenn Sie wissen, dass die Basisklasse niemals virtuelle Methoden aufruft (oder zumindest keine, die überschrieben werden), notieren Sie diese Tatsache, aber duplizieren Sie nicht die bereits vorhandenen Unit-Tests.
Das Testen von Einheiten kann sicherlich bis zum Äußersten gehen - es lohnt sich immer, den Wert, den Sie daraus ziehen, mit dem Aufwand auszugleichen, der Sie kostet.
Mit TDD sollten Sie nicht versuchen, Methoden, sondern Verhalten oder Fähigkeiten Ihres Codes zu testen. Daher können Sie beim Implementieren einer Unterklasse darauf beschränken, nur die Verhaltensweisen zu testen, die sich von der Basisklasse unterscheiden. Schreiben Sie im Zweifelsfall einen neuen Test.
Tags und Links java unit-testing tdd junit