Perché manca lo sviluppo guidato dai test di Joel's Test?

Stavo leggendo questo blog di Joel Spolsky circa 12 passaggi per migliorare il codice . L'assenza di Test Driven Development mi ha davvero sorpreso. Quindi voglio rivolgere la domanda ai Guru. TDD non vale davvero la pena?

Lo sviluppo guidato dai test era praticamente sconosciuto prima della pubblicazione del libro di Kent Beck nel 2002, due anni dopo Joel aveva scritto quel post. La domanda diventa allora perché Joel non ha aggiornato il suo test o se TDD fosse stato meglio conosciuto nel 2000 l'avrebbe incluso tra i suoi criteri?

Credo che non avrebbe, per la semplice ragione che la cosa importante è che hai un processo ben definito, non i dettagli specifici di quel processo. È lo stesso motivo per cui raccomanda il controllo della versione senza specificare un sistema di controllo della versione specifico o consiglia di disporre di un database di bug senza raccomandare un marchio specifico. I buoni team migliorano e si adattano continuamente e utilizzano strumenti e processi che si adattano perfettamente alla loro situazione particolare in quel determinato momento. Per alcuni team, ciò significa sicuramente TDD. Per altre squadre, non così tanto. Se adotti il ​​TDD, assicurati che non provenga da una mentalità cult di cargo .

Joel l'ha affrontato in modo specifico in alcuni punti.

Ha spiegato che i test delle cose non sono in grado di rilevare molti problemi importanti, in particolare quelli soggettivi come "l'interfaccia utente di questo software fa schifo?" Secondo lui, l' eccessiva dipendenza dai test automatici di Microsoft è il modo in cui siamo finiti con Windows Vista.

Ha scritto come, nella sua esperienza, i tipi di bug che gli utenti trovano effettivamente tendono a cadere in due categorie: 1) quelli che si presentano nell'uso comune, che i programmatori si sarebbero trovati se avessero eseguito il proprio codice prima di usarlo o 2) casi limite così oscuri che nessuno avrebbe mai pensato di scrivere dei test per coprirli in primo luogo. Ha dichiarato che solo una percentuale molto piccola dei bug che lui e il suo team risolvono in FogBugz sono il tipo di cose che i test unitari avrebbero colto. (Non riesco a trovare quell'articolo ora, ma se qualcuno sa quale intendo, sentiti libero di modificare il link qui.)

E ha scritto come può essere più un problema che un problema, specialmente quando il tuo progetto diventa un progetto molto grande con molti test unitari, e poi cambi qualcosa (intenzionalmente) e finisci con un numero molto grande di test unitari rotti. Usa specificamente i problemi che il test unitario può causare come motivo per cui non l'ha aggiunto come 13 ° punto al Joel Test, anche quando le persone suggeriscono che dovrebbe farlo.

Lo stesso Joel Spolsky ha risposto a questa domanda nel 2009 :

Joel: C'è un dibattito sullo Test Driven Development ... dovresti avere unit test per tutto, quel genere di cose ... molte persone mi scrivono, dopo aver letto The Joel Test, per dire: "Dovresti avere un 13esimo cosa qui: Test unitari, test unitari al 100% di tutto il tuo codice. "

E questo mi sembra un po 'troppo dottrinario su qualcosa di cui potresti non aver bisogno. Ad esempio, l'idea di una programmazione agile non è quella di fare le cose prima che tu ne abbia bisogno, ma di sfogliarle come necessario. Sento che il test automatico di tutto, molte volte, non ti aiuterà. In altre parole, scriverai moltissimi test unitari per assicurarti che quel codice funzioni davvero e scoprirai sicuramente se non funziona [se non scrivere i test], funziona ancora, ... non lo so, riceverò una mail così per questo perché non lo sto esprimendo così bene. Ma mi sento come se una squadra avesse davvero una copertura del codice al 100% dei propri test unitari, ci sarebbero un paio di problemi. Uno, avrebbero trascorso molto tempo a scrivere test unitari e non sarebbero stati necessariamente in grado di pagare per quel tempo con una qualità migliore. Voglio dire, avrebbero un po 'di qualità migliorata e avrebbero la possibilità di cambiare le cose nel loro codice con la sicurezza che non rompono nulla, ma questo è tutto.

Ma il vero problema con i test unitari, come ho scoperto, è che il tipo di modifiche che tendi a fare man mano che il codice si evolve tende a interrompere una percentuale costante dei test unitari. A volte apporterai una modifica al tuo codice che, in qualche modo, interrompe il 10% dei test unitari. Intenzionalmente. Perché hai cambiato il design di qualcosa ... hai spostato un menu e ora tutto ciò che si basava sul fatto che quel menu fosse lì ... il menu è ora altrove. E così tutti questi test ora si rompono. E devi essere in grado di entrare e ricreare quei test per riflettere la nuova realtà del codice.

Quindi il risultato finale è che, man mano che il tuo progetto diventa sempre più grande, se hai davvero molti test unitari, la quantità di investimento che dovrai fare per mantenere quei test unitari, tenerli aggiornati e mantenere passando, inizia a diventare sproporzionato rispetto all'ammontare del beneficio che ne ricava.

Nessuno tranne Joel poteva rispondere di sicuro. Ma possiamo provare alcune ragioni / osservazioni.

Prima di tutto, i test non sono assenti dal Joel's Test

• I test vengono citati due volte direttamente in 12 passaggi (10 e 12)
• L'esistenza di una build è uno dei primi punti. L'idea di avere build è quella di ottenere la capacità di vedere se si rompono, quindi stiamo (anche) parlando di test qui.

In secondo luogo, l'idea del Joel Test (per quanto ne capisco) è di avere domande veloci, sì-no. "Fai TDD?" non si adatterà esattamente (la risposta potrebbe essere: "alcuni di noi", "per quella parte del codice" o "facciamo test unitari".

In terzo luogo, penso che nessuno abbia detto che (anche Joel) che quei punti in cui "gli unici valgono il tempo" (a proposito, "programmi" non è su di esso), solo che quelle sono buone domande veloci da porre quando arrivano in contatto con un team di software, sia come futuro membro del team o anche come cliente - questa è una lista che ho dato ad alcune persone non tecniche intorno a me che stavano cercando indizi su quanto fosse buono / cattivo il loro reparto IT. Non è tutto, ma è davvero brutto da battere in tre minuti.