Codice riutilizzabilità nei test unitario?

Question

Continuo a sentire le persone dicono di come i test dovrebbero essere semplici, manutenibili, semplici, ma cosa succede con la riutilizzazione del codice nel test unitario?

Prendiamo ad esempio:

def test_some_1():
    ...some code

def test_some_2():
    ...code repeated from test_some_1

.

Non sarebbe meglio incapsulare il codice ripetuto dai due test in una funzione che contiene le asserzioni necessarie?

Ho discusso con alcuni programmatori su questo e non sono d'accordo, hanno detto che i test dovrebbero essere stupidi, quella riutilizzazione del codice non è buona qui. Il motivo per questo è perché non è molto chiaro nella console Django in cui l'affermazione è effettivamente fallita, perché l'affermazione era nella funzione, anche se non sono d'accordo perché l'uso con il naso ti darebbe il nome del test e la traceback, anche se I ragazzi non sono d'accordo, affermando che un test potrebbe essere invocato singolarmente senza naso (e quindi non potevi vedere tutti quei dettagli).

Cosa ne pensi?

.
• è utile utilizzare la riutilizzazione del codice nei test universitari?
• Se la riutilizzazione può / deve essere utilizzata quindi come superare l'altro problema riguardo a Pin-indicando le asserzioni?

Answer 1

I fattori più importanti per la qualità del codice, come chiarezza e leggibilità, sono anche importanti per il codice di prova.Se la ripetizione del codice rende più facile la lettura, dovresti farlo, indipendentemente dal fatto che sia il codice di prova che stai scrivendo e viceversa.

Ad esempio, in un unico pacchetto ho scritto, ho avuto una funzione:

def _test_vector(self, a, b, c):
    # test the function with parameter values a, b, c
    # several asserts here to verify output of function tested

.

Ammesso sia di scrivere tutti i vettori di prova come:

def test_vector1(self):
    self._test_vector(a=42, b=5, c="blah)

.

che, IMO, migliora la chiarezza, poiché i singoli test includono solo le informazioni specifiche per quel test.

Le asserzioni di individuazione dovrebbero essere sempre facili.Anche unittest ti darà una traceback e se il tuo set-up di test non indica una determinata affermazione che avrai difficoltà a debug di eventuali errori di prova e dovrebbe sicuramente passare a qualcosa di sensato.

Answer 2

Come hanno detto i tuoi pari, dovresti scrivere i tuoi test stupidi.Ci sono diversi motivi per questo, il più importante è che tu voglia evitare logiche complesse nei test.Se scrivi i tuoi test "intelligenti" tendono a contenere la stessa logica o simili come il codice che stai cercando di testare.Ciò significa che rischiare di creare lo stesso errore in entrambi i posti e mancherà bug che vuoi trovare.

Un altro motivo è che vuoi che il tuo test funzioni come documentazione del codice che stai cercando di testare.Se il test ha un percorso di esecuzione complesso attraverso molte funzioni e logiche, non sarà così facile da capire.Nel migliore dei mondi vedresti come il codice di produzione ha lo scopo di funzionare solo avendo uno sguardo al test.