Różnica objawia się, gdy w klasie jest więcej niż jedna metoda testowa. setUpClass
i tearDownClass
są uruchamiane raz dla całej klasy; setUp
i tearDown
są 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ą unittest
domyślnym wyjściem po przejściu testu.) Zauważ to setUp
i tearDown
pojawiają się przed i po test1
oraz test2
, podczas gdy setUpClass
i tearDownClass
pojawiają się tylko raz, na początku i na końcu całego przypadku testowego.
unittest
nie uważa, że test przeszedł pomyślnie, dopókitearDown
nie zostanie ukończony bez incydentów.setUp
itearDown
są uruchamiane raz dla każdejtest
metody (czyli łącznie dwa razy w tym przykładzie), alesetUpClass
itearDownClass
są uruchamiane tylko raz dla każdej metody .Jaka jest różnica między
setUp()
iw frameworkusetUpClass()
Pythonaunittest
?Główna różnica (jak zauważyła w odpowiedzi Benjamin Hodgson) polega na tym, że
setUpClass
wywoływana jest tylko raz i to jest przed wszystkimi testami, natomiastsetUp
jest 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 Pythonunittest
).Z
unittest
dokumentacji :i:
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,
setUp
metoda 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
setUpClass
metoda 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, żesetUpClass
jest to rzadko potrzebne. Jest to jednak przydatne, gdy konieczne jest przetestowanie powyższych przykładów (lub podobnych).źródło