Sollte ich unittest private/protected-Methode
Dies ist eigentlich sprachneutral. Aber ich gebe dir Kontext, in python.
Ich habe diese übergeordnete Klasse
class Mammal(object):
def __init__(self):
""" do some work """
def eat(self, food):
"""Eat the food"""
way_to_eat = self._eating_method()
self._consume(food)
def _eating_method(self):
"""Template method"""
def _consume(self, food):
"""Template method"""
Hier eat
ist die einzige öffentliche Methode in der Erwägung, dass _consume
und _eating_method
sind eigentlich geschützte Methoden durchgeführt werden, die von Kind-Klassen.
, Was Sie testen, wenn Sie geschrieben haben, nur die Mammal
Klasse?
Offensichtlich alle 4 Methoden.
Lassen Sie uns nun vorstellen, ein Kind
class Tiger(Mammal):
def _eating_method(self):
"""Template method"""
def _consume(self, food):
"""Template method"""
Blick auf diese Klasse. Es hat nur 2 geschützt Methoden.
Sollte ich zum testen alle 4 Methoden der Tiger
(einschließlich 2 übernommen) - oder testen Sie einfach die änderungen (nur overrided 2 Methoden)?
Was ist der Idealfall?
Das hängt davon ab. Normalerweise ist der
eat
-Methode getestet, mit allen möglichen Ergebnis _eating_method
und _consume
. So werden nur die geänderten Methoden getestet werden müssen.InformationsquelleAutor Shiplu Mokaddim | 2014-12-30
Du musst angemeldet sein, um einen Kommentar abzugeben.
Aus theoretischer Sicht, Sie brauchen nur zu prüfen, die öffentlichen Methoden Ihrer instanziierbaren Klassen (in standard-OOP-Sprachen). Es gibt keinen Punkt in der Prüfung das interne Verhalten, weil alle Sie wollen, ist "die Ausgabe für diesen Eingang" (für eine bestimmte Methode oder für die gesamte Klasse). Sie sollten versuchen, Sie zu respektieren, so viel wie Sie können, weil es zwingt Sie dazu bitten, einige Fragen über die Kapselung Ihrer Klasse und die bereitgestellte Schnittstelle, die entscheidend sein können für Ihre Architektur.
Aus pragmatischer Sicht, Sie haben manchmal etwas abstrakte helper-Klassen ohne konkrete Unterklasse implementiert oder die abstrakte Klasse factoring-90+% seiner untergeordneten Klassen und wo es wäre zu hart, um zu testen, die Ausgabe ohne einstecken in eine geschützte Methode. In diesen Arten von Fällen, können Sie mock eine Unterklasse.
In Ihrer einfachen Beispiels, würde ich dir empfehlen, nur test der Klasse
Tiger
(und nur die öffentliche Methodeeat
).Tiger.eat()
, richtig?Ja, Sie können einfach testen, diese Methode (die einzige, die öffentlich ist).
InformationsquelleAutor Gnucki
Den Weg würde ich diesen Ansatz ist:
Mammal
bietet minimale Implementierungen der beiden protected Methoden auf, die es Ihnen ermöglichen unit-Tests das Verhalten der öffentlichen Methoden.Mammal
sind, aber behaupten, das Verhalten, die spezifisch für die Unterklasse.Dies sollte Ihnen die nötige Testabdeckung mit einer minimalen Anzahl von tests.
Ein alternativer Ansatz wäre zum testen der Unterklassen nur, und auf einem der Unterklasse unit-tests bestehe auch die spezifischen Funktionen der
Mammal
. Dies vermeidet die Notwendigkeit der Schaffung eines spezifischen Tests Unterklasse, jedoch zwei Nachteile:Mammal
isoliert, und daher die tests auf derMammal
- spezifischen code, sind anfällig zu scheitern, weil Probleme in der Unterklasse.Mammal
getestet werden.InformationsquelleAutor robjohncox
Beim testen, Sie sollten sich auf das Verhalten außerhalb des Codes, nicht auf Implementierungsdetails. Ich weiß nicht, den Kontext, so werde ich nur einige riesige Annahmen hier.
Tun Sie wirklich über das Verhalten einer (möglicherweise abstrakte) Oberklasse Säugetier? Ist die Wiederverwendung durch Vererbung-Beziehung so wichtig? Was ist, wenn Sie sich entscheiden, ersetzen Sie die Vererbung Beziehung zu einer Komposition-basierte Strategie?
Ich würde konzentrieren sich auf Tests, die das Verhalten der Klassen, die Sie tatsächlich interessieren: "Hat ein Tiger Essen wie erwartet?", statt der Prüfung eine abstrakte Superklasse, die wird nur eingeführt, um die Wiederverwendung von code.
InformationsquelleAutor prgmtc