Che tipo di codice Kent Beck eviterà il test unitario? [duplicare]

Question

Che tipo di codice Kent Beck eviterà il test unitario? [duplicare]

#1 da (7 voti)
#2 da (4 voti)

9

Ho seguito alcuni dei post di TDD Dead? su youtube, e uno dei Le cose che mi hanno sorpreso è che Kent Beck sembra riconoscere che ci sono solo alcuni tipi di programmi che non valgono la pena di effettuare test unitari. Ad esempio, proprio qui DHH dice che Kent Beck è

... very happy to say "Well, TDD doesn't fit in this case, I'm just going to bail"

È frustrante per me che Kent Beck sembri riconoscerlo, ma nessuno gli chiede di approfondire o dare esempi concreti. Mi piacerebbe conoscere le situazioni in cui Kent Beck pensa che TDD sia una brutta cosa. Nessuno può leggere la sua mente o parlare per lui, ma spero che sia stato abbastanza trasparente attraverso i suoi libri / tweet / qualsiasi cosa per qualcuno in grado di rispondere.

Non prenderò necessariamente quello che dice come gospel, ma sarebbe utile sapere che le volte in cui ho provato a TDD e mi sono sentito impossibile / inutile sono le situazioni in cui si sarebbe salvato da solo. Oppure, se risultasse che avrebbe testato quel codice mi suggerirebbe che mi stavo avvicinando al processo molto male. Penso anche che sarebbe illuminante capire perché farebbe cauzione su tali progetti.

La mia opinione sul perché questo non è un duplicato di " Quando è opportuno non testare l'unità? "

Dopo aver scansito quelle risposte non sono soddisfatto. Ad esempio, guarda la risposta di UncleBob . Non riconosce nemmeno che esiste una situazione del genere. Penso davvero che ci sia un valore nella comprensione della posizione di Kent Beck , non solo di un generale, "Qual è la tua opinione?" tipo di domanda. Dopo tutto, è il padre di TDD.

testing unit-testing

posta Daniel Kaplan 11.06.2014 - 21:04

fonte

2 risposte

Leggi altre domande sui tag testing unit-testing

Come incapsulare le variabili "globali" in C #? /la migliore pratica Kanban: come scegliere la dimensione dell'elemento di lavoro

score 7 · Answer 1

In Explained Programming , Kent Beck non dice molto su cosa in particolare per non testare l'unità, ma fornisce le sue motivazioni su cosa dovrebbe essere testato (pagina 116-118 nella mia edizione):

It is impossible to test absolutely everything, without the tests being as complicated and error-prone as the code. It is suicide to test nothing (in this sense of isolated, automatic tests). So, of all the things you can imagine testing, what should you test?

You should test things that might break. If code is so simple that it can't possibly break, and you measure that the code in question doesn't actually break in practice, then you shouldn't write a test for it...

Testing is a bet. The bet pays off when your expectations are violated [when a test that you expect to pass fails, or when a test that you expect to fail passes]... So, if you could, you would only write those tests that pay off. Since you can't know which tests would pay off (if you did, then you would already know and you wouldn't be learning anything), you write tests that might pay off. As you test, you reflect on which kinds of tests tend to pay off and which don't, and you write more of the ones that do pay off, and fewer of the ones that don't.

Per riassumere la sua posizione, a quanto pare non consiglia di provare:

Codice banalmente semplice
Tutto ciò che non puoi testare "senza che i test siano complicati e soggetti a errori come il codice." (Tuttavia, senza dubbio raccomanderebbe vivamente varie tecniche agili, XP e OO per ridurre la complessità in modo che possa essere testato. Ad esempio, scrive: "Più esperienza proverò a scrivere test, più scopro che posso scrivere test per requisiti non funzionali - come le prestazioni o l'adesione del codice agli standard "(p. 45).)
Codice legacy (codice per cui esiste un test) che non necessita di essere toccato (vedi p. 126)
Tutto ciò per cui il test non "ripaga"

Un caso specifico: Kent Beck ha detto che è non un fan di mock , e sottolinea con forza che i test unitari devono essere "indipendenti" (nel senso che i test non interagiscono tra loro, un test fallito non fa fallire gli altri). Ne deduco che non testerebbe il codice che dipende pesantemente dall'integrazione o da molti oggetti che collaborano insieme. (Anche in questo caso, sono sicuro che avrebbe sostenuto tecniche agili, XP e OO per minimizzare questo.)

score 4 · Answer 2

Sto solo guardando i video registrati e penso che abbia detto qualcosa in questo senso come criterio per non test delle unità :

Ha bisogno di un sacco di beffe.
Non riesco a capire un design migliore.
Necessità di consegna / spedizione.

Nella mia esperienza ci sono almeno alcune situazioni in cui i test unitari devono essere attentamente valutati:

Il codice è banale. Per esempio. getter / setter.
Il codice è codice di colla tra più componenti esterni. È qui che dovresti ricorrere a qualche derisione estrema per simulare quei componenti esterni nella misura in cui il tuo test non ha senso ed è un ostacolo al refactoring. Il codice che interagisce con hardware, database, servizi di rete, ecc. Può essere un esempio di questo.
Esiste già una copertura molto buona in altri test che colpisce ciò che è il candidato per il test dell'unità.
Puoi ragionare sulla correttezza attraverso altri mezzi.
Non c'è tempo o valore aziendale per scrivere il codice + test unitari, ad es. avere un codice di scarsa qualità senza test significa che la tua startup sopravviverà al mese prossimo perché puoi dimostrare il tuo prodotto a un VC senza avere nulla e il tuo avvio è morto.

Esempi di buone situazioni per il test (unitario) sarebbero:

Percorso più breve in un algoritmo grafico (in cui dovresti disporre di grafici di input di esempio in cui conosci il percorso più breve)
AES codifica / decodifica dove useresti i vettori di test standard per verificare che l'algoritmo sia un'implementazione conforme.
codificatore video h.264

Penso che fossero anche abbastanza chiari che ciò che è importante è il feedback e il test unitario è uno strumento nella cassetta degli attrezzi per ottenere quel feedback. Sono stati anche molto chiari sul fatto che TDD è uno stile particolare di feedback e che lo stile che usi dipende anche dalla tua personalità e da come ti avvicini alla risoluzione dei problemi.