Qual è la differenza tra setUp()e setUpClass()nel unittestframework Python ? Perché l'installazione dovrebbe essere gestita in un metodo rispetto all'altro?

Voglio capire quale parte della configurazione viene eseguita nelle funzioni setUp()e setUpClass(), nonché con tearDown()e tearDownClass().

La differenza si manifesta quando hai più di un metodo di test nella tua classe. setUpClasse tearDownClassvengono eseguiti una volta per l'intera classe; setUpe tearDownvengono eseguiti prima e dopo ogni metodo di prova.

Per esempio:

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

Quando esegui questo test, stampa:

setUpClass
setUp
test1
tearDown
.setUp
test2
tearDown
.tearDownClass

(I punti ( .) sono unittestl'output predefinito quando un test viene superato.) Osservalo setUpe tearDowncompaiono prima e dopo test1 e test2 , mentre setUpClasse tearDownClasscompaiono solo una volta, all'inizio e alla fine dell'intero test case.

Qual è la differenza tra setUp()e setUpClass()nel unittestframework Python ?

La differenza principale (come notato nella risposta di Benjamin Hodgson) è che setUpClassviene chiamato solo una volta e cioè prima di tutti i test, mentre setUpviene chiamato immediatamente prima di ogni test. (NB: lo stesso vale per i metodi equivalenti in altri framework di test xUnit, non solo in Python unittest.)

Dalla unittest documentazione :

setUpClass()

Un metodo di classe chiamato prima dell'esecuzione dei test in una singola classe. setUpClass viene chiamato con la classe come unico argomento e deve essere decorato come un metodo di classe ():

@classmethod
def setUpClass(cls):
    ...

e:

setUp()

Metodo chiamato per preparare il dispositivo di prova. Viene chiamato immediatamente prima di chiamare il metodo di test; a parte AssertionError o SkipTest, qualsiasi eccezione sollevata da questo metodo sarà considerata un errore piuttosto che un fallimento del test. L'implementazione predefinita non fa nulla.

Perché l'installazione dovrebbe essere gestita in un metodo piuttosto che nell'altro?

Questa parte della domanda non ha ancora ricevuto risposta. Come da mio commento in risposta alla risposta di Gearon, il setUpmetodo è inteso per elementi del dispositivo che sono comuni a tutti i test (per evitare di duplicare quel codice in ogni test). Trovo che questo sia spesso utile in quanto la rimozione della duplicazione (di solito) migliora la leggibilità e riduce il carico di manutenzione.

Il setUpClassmetodo è per elementi costosi che preferiresti dover fare solo una volta, come l'apertura di una connessione al database, l'apertura di un file temporaneo sul filesystem, il caricamento di una libreria condivisa per il test, ecc. Fare queste cose prima di ogni test rallenterebbe il suite di test troppo, quindi lo facciamo solo una volta prima di tutti i test. Questa è una leggera degradazione nell'indipendenza dei test ma un'ottimizzazione necessaria in alcune situazioni. Probabilmente, non si dovrebbero fare queste cose negli unit test poiché di solito è possibile deridere il database / filesystem / libreria / qualsiasi cosa senza usare la cosa reale. In quanto tale, trovo che setUpClasssia raramente necessario. Tuttavia, è utile quando si rende necessario testare gli esempi precedenti (o simili).