Ich würde gerne etwas über die Testmethodik erfahren.
Nehmen wir an, wir haben Klasse A und B. Klasse B verwendet Funktionalität der Klasse A. Die B-Klasse ist vollständig getestet und somit wird auch eine Testabdeckung indirekt für Klasse A angewendet.
Soll ich vollständige Tests direkt für Klasse A schreiben? Oder sollte ich nur die nicht getestete A-Klassen-Funktionalität testen?
Ich frage, weil vielleicht in Zukunft die Möglichkeit besteht, dass die B-Klasse entfernt oder modifiziert wird, so dass sie möglicherweise nicht die gleiche Funktionalität aus der A-Klasse verwendet, so dass einige Methoden möglicherweise nicht getestet werden. Was würdest du tun?
IMO, Sie sollten das Verhalten von B testen, ohne darauf zu achten, dass A bereits getestet wurde.
Tatsächlich gibt es drei Fälle:
A und B GEHÖREN DER GLEICHEN EBENE:
Wenn A durch den Refactor-Zyklus (Extraktklasse) von B erstellt wird (passiert oft beim Üben einer guten TDD), dann sollte A TOTALLY nicht getestet werden! Keine Notwendigkeit, es überhaupt zu testen!
In der Tat sollte die Code-Struktur (in diesem Fall die Trennung der Klassen / SRP) unabhängig vom Unit Konzept sein; B und A gehören in diesem Fall zur selben Einheit.
Wenn A BEVOR B vorhanden ist, sollte B nicht auf dieser Tatsache basieren und das gesamte Verhalten von B sollte getestet werden.
A und B gehören nicht zu derselben Ebene (distinct Grenzen zum Beispiel):
B eine GUI-Klasse ist und A eine Business-Klasse, dann sollte A beim Testen von B verdoppelt / verspottet werden, und auch A sollte einen vollständigen Test dafür haben. < br>
In der Tat sollte Domain-Architektur nicht mit behavior/feature Ahnung gemischt werden. Um zu verstehen, warum, lesen Sie diesen Artikel von Onkel Bob, der sich mit diesem Konzept befasst:
Auszug davon:
Es ist ein häufiges Missverständnis, dass das Design der Tests widerspiegeln muss das Design des Produktionscodes. TDD erfordert nicht, wie der Autor schlägt vor, "dass jede Einheit in Ihrem System mit einem gepaart ist gut entworfenen [...] Unit-Test. "Das ist einer der Gründe dafür viele von uns haben aufgehört, sie "Einheits" -Tests zu nennen.
Hinweis: TDD kümmert sich nicht um "Zukunft", im Gegenteil, es hilft Ihnen, so viel Code zu schreiben, wie Sie brauchen, nicht mehr. Daher sollten Sie sich keine Sorgen machen:
in Zukunft wird es möglich sein, dass die B-Klasse sein wird entfernt oder geändert
Wenn Sie gute Tests geschrieben haben (ich bevorzuge das Wort "specs"), würde eine solche Entfernung sofort erkannt werden.
Ja, Sie sollten A vollständig testen.
B könnte sich irgendwann ändern, nur weil A jetzt verwendet wird, heißt das nicht immer.
B verwendet möglicherweise nicht die gesamte Funktionalität von A , was bedeutet, dass Sie nicht Ihren gesamten Code testen.
Schreiben Sie auf jeden Fall die vollständigen Tests für die Klasse A. Sie haben Ihre eigene Frage hier beantwortet:
(...)maybe in the future there will be possibility that the B class will be removed or modified in the way that it might not use the same functionality from A class so it might leave some methods untested.
Der allgemeine Gedanke hinter Unittesting ist, dass jede Einheit aus einer Unit of Work besteht. Dies kann so klein wie eine Methode oder so groß wie mehrere Methoden zusammenarbeiten.
Sie haben bereits das Szenario behandelt, in dem B von A abhängig ist, aber von Ihrer Geschichte können wir annehmen, dass A auch separat verwendet wird. Daher sollte A auch getestet werden, da es sich um eine separate Arbeitseinheit handelt.
B sollte nur A über eine Schnittstelle IA
verwendenTesten Sie B über seine öffentliche Schnittstelle und A über seine öffentliche Schnittstelle.
Beide sollten getestet werden.
Sie sollten zuerst testen A, dann B. Wenn Sie bei B einen Testfehler erhalten, haben Sie nicht genug Diagnose, um zu wissen, ob sie aus dem Code von B stammt oder in A's.
Bei Unit-Tests geht es nicht nur um "bestanden / nicht bestanden", sondern um Diagnose des Problems .
Tags und Links java unit-testing