Was ist der Unterschied zwischen setUp()und setUpClass()im Python- unittestFramework? Warum sollte das Setup in einer Methode über der anderen behandelt werden?

Ich möchte verstehen , was Teil der Installation in den erfolgt setUp()und setUpClass()Funktionen, sowie mit tearDown()und tearDownClass().

Der Unterschied zeigt sich, wenn Sie mehr als eine Testmethode in Ihrer Klasse haben. setUpClassund tearDownClasswerden einmal für die ganze Klasse ausgeführt; setUpund tearDownwerden vor und nach jeder Testmethode ausgeführt.

Beispielsweise:

class Example(unittest.TestCase):
    @classmethod
    def setUpClass(cls):
        print("setUpClass")

    def setUp(self):
        print("setUp")

    def test1(self):
        print("test1")

    def test2(self):
        print("test2")

    def tearDown(self):
        print("tearDown")

    @classmethod
    def tearDownClass(cls):
        print("tearDownClass")

Wenn Sie diesen Test ausführen, wird Folgendes gedruckt:

setUpClass
setUp
test1
tearDown
.setUp
test2
tearDown
.tearDownClass

(Die Punkte ( .) sind unittestdie Standardausgabe, wenn ein Test bestanden wurde.) Beachten Sie dies setUpund tearDownerscheinen vor und nach test1 und test2 , während setUpClassund tearDownClassnur einmal, am Anfang und Ende des gesamten Testfalls.

Was ist der Unterschied zwischen setUp()und setUpClass()im Python- unittestFramework?

Der Hauptunterschied (wie in der Antwort von Benjamin Hodgson erwähnt) besteht darin, dass setUpClasser nur einmal und vor allen Tests setUpaufgerufen wird , während er unmittelbar vor jedem einzelnen Test aufgerufen wird. (Hinweis: Gleiches gilt für die entsprechenden Methoden in anderen xUnit-Testframeworks, nicht nur für Pythons unittest.)

Aus der unittest Dokumentation :

setUpClass()

Eine Klassenmethode, die aufgerufen wird, bevor Tests in einer einzelnen Klasse ausgeführt werden. setUpClass wird mit der Klasse als einzigem Argument aufgerufen und muss als Klassenmethode () dekoriert werden:

@classmethod
def setUpClass(cls):
    ...

und:

setUp()

Methode zur Vorbereitung der Prüfvorrichtung. Dies wird unmittelbar vor dem Aufruf der Testmethode aufgerufen. Mit Ausnahme von AssertionError oder SkipTest wird jede durch diese Methode ausgelöste Ausnahme eher als Fehler als als Testfehler betrachtet. Die Standardimplementierung führt nichts aus.

Warum sollte das Setup in einer Methode über der anderen behandelt werden?

Dieser Teil der Frage wurde noch nicht beantwortet. Gemäß meinem Kommentar als Antwort auf die Antwort von Gearon ist die setUpMethode für Elemente des Geräts gedacht, die allen Tests gemeinsam sind (um zu vermeiden, dass dieser Code in jedem Test dupliziert wird). Ich finde dies oft nützlich, da das Entfernen von Duplikaten (normalerweise) die Lesbarkeit verbessert und den Wartungsaufwand verringert.

Die setUpClassMethode ist für teure Elemente gedacht, die Sie lieber nur einmal ausführen müssen, z. B. das Öffnen einer Datenbankverbindung, das Öffnen einer temporären Datei im Dateisystem, das Laden einer gemeinsam genutzten Bibliothek zum Testen usw. Wenn Sie solche Dinge vor jedem Test ausführen, wird der Vorgang verlangsamt Testsuite zu viel, deshalb machen wir es nur einmal vor allen Tests. Dies ist eine leichte Verschlechterung der Unabhängigkeit der Tests, in einigen Situationen jedoch eine notwendige Optimierung. Vermutlich sollte man solche Dinge nicht in Unit-Tests tun, da es normalerweise möglich ist, die Datenbank / das Dateisystem / die Bibliothek / was auch immer zu verspotten, ohne die reale Sache zu verwenden. Als solches finde ich, dass setUpClassdas selten benötigt wird. Dies ist jedoch nützlich, wenn das Testen der obigen Beispiele (oder ähnlicher Beispiele) erforderlich wird.