Perché ripetere te stesso scrivendo test è così fortemente incoraggiato?
Sembra che i test esprimano sostanzialmente la stessa cosa del codice, e quindi è un duplicato (nel concetto, non implementazione) del codice. L'obiettivo finale di DRY non sarebbe l'eliminazione di tutto il codice di test?
Risposte:
Credo che questo sia un malinteso in qualsiasi modo mi venga in mente.
Il codice di test che verifica il codice di produzione non è affatto simile. Dimostrerò in Python:
def multiply(a, b):
"""Multiply ``a`` by ``b``"""
return a*b
Quindi un semplice test sarebbe:
def test_multiply():
assert multiply(4, 5) == 20
Entrambe le funzioni hanno una definizione simile ma entrambe fanno cose molto diverse. Nessun codice duplicato qui. ;-)
Si verifica inoltre che le persone scrivano test duplicati essenzialmente con un'asserzione per funzione di test. Questa è follia e ho visto persone farlo. Questa è una cattiva pratica.
def test_multiply_1_and_3():
"""Assert that a multiplication of 1 and 3 is 3."""
assert multiply(1, 3) == 3
def test_multiply_1_and_7():
"""Assert that a multiplication of 1 and 7 is 7."""
assert multiply(1, 7) == 7
def test_multiply_3_and_4():
"""Assert that a multiplication of 3 and 4 is 12."""
assert multiply(3, 4) == 12
Immagina di farlo per oltre 1000 righe di codice efficaci. Al contrario, esegui il test in base alla "funzione":
def test_multiply_positive():
"""Assert that positive numbers can be multiplied."""
assert multiply(1, 3) == 3
assert multiply(1, 7) == 7
assert multiply(3, 4) == 12
def test_multiply_negative():
"""Assert that negative numbers can be multiplied."""
assert multiply(1, -3) == -3
assert multiply(-1, -7) == 7
assert multiply(-3, 4) == -12
Ora, quando le funzionalità vengono aggiunte / rimosse, devo solo considerare di aggiungere / rimuovere una funzione di test.
Potresti aver notato che non ho applicato i forloop. Questo perché ripetere alcune cose è buono. Quando avrei applicato i loop, il codice sarebbe molto più breve. Ma quando un'asserzione fallisce potrebbe offuscare l'output mostrando un messaggio ambiguo. In questo caso, i test saranno meno utili e sarà necessario un debugger per verificare dove le cose vanno male.
assert multiply(1,3)fallirebbe ma non otterrai anche il rapporto di test fallito assert multiply(3,4).
def test_shuffleesegue due asserzioni.
assert multiply(*, *) == *modo da poter definire una assert_multiplyfunzione. Nello scenario attuale non importa dal conteggio delle righe e dalla leggibilità, ma dai test più lunghi è possibile riutilizzare asserzioni complicate, dispositivi, codice di generazione di dispositivi, ecc ... Non so se questa è una buona pratica, ma di solito lo faccio Questo.
Sembra che i test esprimano sostanzialmente la stessa cosa del codice, e quindi è un duplicato
No, questo non è vero.
I test hanno uno scopo diverso rispetto all'implementazione:
L'obiettivo finale di DRY non sarebbe l'eliminazione di tutto il codice di test?
No, l'obiettivo finale di DRY significherebbe in realtà l'eliminazione di tutto il codice di produzione .
Se i nostri test potessero essere le specifiche perfette di ciò che vogliamo che faccia il sistema, dovremmo semplicemente generare automaticamente il corrispondente codice di produzione (o binari), rimuovendo efficacemente la base di codice di produzione in sé.
Questo è in realtà ciò che pretendono di raggiungere approcci come l'architettura guidata dai modelli: un'unica fonte di verità progettata dall'uomo da cui tutto deriva dal calcolo.
Non penso che il contrario (sbarazzarsi di tutti i test) sia desiderabile perché:
Poiché il test unitario consiste nel rendere più difficili le modifiche involontarie , a volte può rendere anche le modifiche intenzionali più difficili. Questo fatto è effettivamente correlato al principio DRY.
Ad esempio, se si dispone di una funzione MyFunctionche viene chiamata nel codice di produzione in un solo posto e si scrivono 20 unità di test per essa, si può facilmente finire per avere 21 posizioni nel codice in cui viene chiamata quella funzione. Ora, quando devi cambiare la firma MyFunction, la semantica o entrambi (perché alcuni requisiti cambiano), hai 21 posti da cambiare invece di uno solo. E la ragione è davvero una violazione del principio DRY: hai ripetuto (almeno) la stessa chiamata di funzione a MyFunction21 volte.
L'approccio corretto per un caso del genere è applicare il principio DRY anche al codice di test: durante la scrittura di 20 unit test, incapsulare le chiamate MyFunctionnei test unitari in poche funzioni di supporto (idealmente solo una), che vengono utilizzate dal 20 test unitari. Idealmente, si ottiene solo due posizioni nel codice che chiama MyFunction: una dal codice di produzione e una dai test unitari. Quindi, quando devi cambiare la firma in un MyFunctionsecondo momento, avrai solo pochi punti da cambiare nei tuoi test.
"Pochi posti" sono ancora più di "un posto" (ciò che si ottiene senza test unitari), ma i vantaggi di avere test unitari dovrebbero superare notevolmente il vantaggio di avere meno codice da modificare (altrimenti si esegue completamente il test unitario sbagliato).
Una delle maggiori sfide per la creazione di software è l'acquisizione dei requisiti; vale a dire rispondere alla domanda "cosa dovrebbe fare questo software?" Il software ha bisogno di requisiti precisi per definire con precisione ciò che il sistema deve fare, ma quelli che definiscono le esigenze di sistemi e progetti software spesso includono persone che non hanno un background software o formale (matematico). La mancanza di rigore nella definizione dei requisiti ha costretto lo sviluppo del software a trovare un modo per convalidare il software ai requisiti.
Il team di sviluppo si è trovato a tradurre la descrizione colloquiale di un progetto in requisiti più rigorosi. La disciplina dei test si è consolidata come il punto di controllo per lo sviluppo del software, per colmare il divario tra ciò che un cliente dice di voler e ciò che il software capisce di voler. Sia gli sviluppatori di software che il team di qualità / test formano la comprensione delle specifiche (informali) e ogni (indipendentemente) scrive software o test per assicurarsi che la loro comprensione sia conforme. L'aggiunta di un'altra persona per comprendere i requisiti (imprecisi) ha aggiunto domande e prospettive diverse per affinare ulteriormente la precisione dei requisiti.
Dato che ci sono sempre stati test di accettazione, è stato naturale espandere il ruolo di test per scrivere test automatici e unitari. Il problema era che significava assumere programmatori per fare dei test, e quindi hai ristretto la prospettiva dalla garanzia della qualità ai programmatori che facevano i test.
Detto questo, probabilmente stai facendo dei test sbagliati se i tuoi test differiscono poco dai programmi reali. Il suggerimento di Msdy sarebbe quello di concentrarsi maggiormente su cosa nei test e meno su come.
L'ironia è che, anziché acquisire una specifica formale dei requisiti dalla descrizione colloquiale, l'industria ha scelto di implementare test puntuali come codice per automatizzare i test. Invece di produrre requisiti formali a cui il software potrebbe essere costruito per rispondere, l'approccio adottato è stato quello di testare alcuni punti, piuttosto che avvicinarsi alla costruzione di software usando la logica formale. Questo è un compromesso, ma è stato abbastanza efficace e relativamente efficace.
Se ritieni che il tuo codice di test sia troppo simile al tuo codice di implementazione, ciò potrebbe indicare che stai utilizzando eccessivamente un framework di derisione. I test basati su simulazioni a un livello troppo basso possono finire con l'impostazione del test che assomiglia molto al metodo testato. Prova a scrivere test di livello superiore che hanno meno probabilità di interrompersi se cambi l'implementazione (so che può essere difficile, ma se riesci a gestirlo avrai come risultato una suite di test più utile).
I test unitari non dovrebbero includere una duplicazione del codice in prova, come è già stato notato.
Vorrei aggiungere, tuttavia, che i test unitari in genere non sono così ASCIUTTI come il codice "produzione", perché l'installazione tende ad essere simile (ma non identica) tra i test ... specialmente se si dispone di un numero significativo di dipendenze che si stanno prendendo in giro / fingendo.
È ovviamente possibile trasformare questo genere di cose in un metodo di configurazione comune (o in una serie di metodi di configurazione) ... ma ho scoperto che quei metodi di configurazione tendono ad avere lunghi elenchi di parametri ed essere piuttosto fragili.
Quindi sii pragmatico. Se riesci a consolidare il codice di installazione senza compromettere la manutenibilità, fallo sicuramente. Ma se l'alternativa è un insieme complesso e fragile di metodi di installazione, un po 'di ripetizione nei metodi di prova è OK.
Un evangelista locale TDD / BDD dice così:
"Il tuo codice di produzione dovrebbe essere ASCIUTTO. Ma va bene che i tuoi test siano" umidi "."
Sembra che i test esprimano sostanzialmente la stessa cosa del codice, e quindi è un duplicato (nel concetto, non implementazione) del codice.
Questo non è vero, i test descrivono i casi d'uso, mentre il codice descrive un algoritmo che passa i casi d'uso, quindi più generale. Con TDD inizi a scrivere casi d'uso (probabilmente basati sulla storia dell'utente) e successivamente a implementare il codice necessario per passare questi casi d'uso. Quindi scrivi un piccolo test, un piccolo pezzo di codice, e successivamente rifatti se necessario per sbarazzarti delle ripetizioni. Funziona così.
Dai test possono esserci anche ripetizioni. Ad esempio è possibile riutilizzare gli apparecchi, il codice di generazione degli apparecchi, le asserzioni complicate, ecc ... Di solito lo faccio, per evitare bug nei test, ma di solito dimentico di provare prima se un test fallisce davvero e può davvero rovinare la giornata , quando stai cercando il bug nel codice per mezz'ora e il test è sbagliato ... xD