Jaka jest różnica między setUp()iw frameworku setUpClass()Pythona unittest? Dlaczego konfiguracja miałaby być obsługiwana jedną metodą zamiast drugiej?

Chcę zrozumieć, jaka część konfiguracji jest wykonywana w funkcjach setUp()i setUpClass(), a także w tearDown()i tearDownClass().

Różnica objawia się, gdy w klasie jest więcej niż jedna metoda testowa. setUpClassi tearDownClasssą uruchamiane raz dla całej klasy; setUpi tearDownsą uruchamiane przed i po każdej metodzie testowej.

Na przykład:

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")

Po uruchomieniu tego testu drukuje:

setUpClass
setUp
test1
tearDown
.setUp
test2
tearDown
.tearDownClass

(Kropki ( .) są unittestdomyślnym wyjściem po przejściu testu.) Zauważ to setUpi tearDownpojawiają się przed i po test1 oraz test2 , podczas gdy setUpClassi tearDownClasspojawiają się tylko raz, na początku i na końcu całego przypadku testowego.

Jaka jest różnica między setUp()iw frameworku setUpClass()Pythona unittest?

Główna różnica (jak zauważyła w odpowiedzi Benjamin Hodgson) polega na tym, że setUpClasswywoływana jest tylko raz i to jest przed wszystkimi testami, natomiast setUpjest wywoływana bezpośrednio przed każdym testem. (Uwaga: to samo dotyczy równoważnych metod w innych strukturach testowych xUnit, nie tylko w języku Python unittest).

Z unittest dokumentacji :

setUpClass()

Metoda klasowa wywoływana przed uruchomieniem testów w klasie indywidualnej. setUpClass jest wywoływana z klasą jako jedynym argumentem i musi być udekorowana jako metoda class ():

@classmethod
def setUpClass(cls):
    ...

i:

setUp()

Metoda wywołana w celu przygotowania osprzętu testowego. Jest to wywoływane bezpośrednio przed wywołaniem metody testowej; inny niż AssertionError lub SkipTest, każdy wyjątek zgłoszony przez tę metodę będzie traktowany jako błąd, a nie niepowodzenie testu. Domyślna implementacja nic nie robi.

Dlaczego konfiguracja miałaby być obsługiwana jedną metodą zamiast drugiej?

Na tę część pytania nie ma jeszcze odpowiedzi. Zgodnie z moim komentarzem w odpowiedzi na odpowiedź Gearona, setUpmetoda jest przeznaczona dla elementów oprawy, które są wspólne dla wszystkich testów (aby uniknąć powielania tego kodu w każdym teście). Uważam, że jest to często przydatne, ponieważ usuwanie duplikatów (zwykle) poprawia czytelność i zmniejsza obciążenie związane z konserwacją.

Ta setUpClassmetoda jest przeznaczona dla kosztownych elementów, które wolałbyś wykonać tylko raz, takich jak otwarcie połączenia z bazą danych, otwarcie pliku tymczasowego w systemie plików, załadowanie biblioteki współdzielonej do testów itp. Wykonywanie takich czynności przed każdym testem spowolniłoby zestawu testów za dużo, więc robimy to raz przed wszystkimi testami. Jest to nieznaczne pogorszenie niezależności testów, ale w niektórych sytuacjach konieczna optymalizacja. Prawdopodobnie nie powinno się robić takich rzeczy w testach jednostkowych, ponieważ zwykle można mockować bazę danych / system plików / bibliotekę / cokolwiek bez użycia prawdziwej rzeczy. W związku z tym uważam, że setUpClassjest to rzadko potrzebne. Jest to jednak przydatne, gdy konieczne jest przetestowanie powyższych przykładów (lub podobnych).