Se TDD riguarda il design, perché ne ho bisogno? [chiuso]

TDD non mi aiuta solo a raggiungere il miglior design definitivo, mi aiuta ad arrivare in pochi tentativi.

Avevo due o tre coltellate a un problema prima di decidere quale disegno pensavo fosse il migliore. Ora, quello stesso tempo è impiegato per scrivere test e focalizzare la mia mente sul design corretto. E, come bonus, mi lascia con una serie di test ripetibili. Win!

Detto questo, ci saranno inevitabilmente persone per le quali TDD non offre nulla. Finché hanno ancora test automatici e ripetibili alla fine, va bene.

Ciò che questo particolare guru TDD sta davvero cercando di dire non è che TDD sia un processo di progettazione (sebbene un numero di persone lo abbia interpretato sfortunatamente in questo modo). Il messaggio qui è che l'utilizzo di un processo come TDD, se lo si fa giusto , tenderà a migliorare la progettazione generale.

Il concetto fondamentale è uno che è molto più vecchio di TDD; progettazione per testabilità . Se rispetti rigorosamente i principi SOLID , in particolare Principio di responsabilità singola , troverai codice molto facile da testare. D'altra parte, se tendi ad essere un po 'più scadente nella tua progettazione, probabilmente troverai il processo di scrittura dei test unitari per costringerti a farlo più spesso, per evitare la frustrazione di (a) capire ciò che deve essere testato e (b) dedicare più tempo all'impostazione delle dipendenze rispetto alla scrittura dei test effettivi.

Non avere per seguire TDD per ottenere i benefici di questo, ma fa aiuta a scrivere i test in anticipo - preferibilmente molto presto dopo aver implementato una classe, se non prima o durante. Se aspetti troppo a lungo, corri il rischio dei test "sporco ibrido" di cui parla l'autore, che non hanno molto valore perché sono fragili e tendono a rompersi durante il refactoring inoffensivo - per non parlare del fare di più -scale ridisegna un processo estremamente difficile.

Non puoi sapere se stai veramente progettando la testabilità se non scrivi test, e i "test delle caratteristiche" casuali con solo il 15% di copertura del codice non contano.

Naturalmente puoi creare buoni progetti senza mai scrivere un singolo test - ma sei sicuro che siano dei grandi progetti? Come fai a sapere, se non sono specificati chiaramente dai test? Il test svela un sacco di problemi, e mentre un processo di QA può trovare bug visibili, non non porta a decisioni di progettazione scadenti.

Risposta semplicistica proveniente da qualcuno che si impegna ad imparare TDD: non hai bisogno , ma il vantaggio principale che ti dà è, semplicemente, confidenza : la fiducia che la tua applicazione funziona. Fiducia che i casi d'uso sono soddisfatti. Fiducia che la tua logica sia valida per il modulo "Foobar". Fiducia che il tuo codice sia strutturato correttamente per essere mantenibile ed estendibile a sei mesi lungo la strada quando il CEO vuole aggiungere una nuova caratteristica pazzesca di cui ha letto. Fiducia che, quando la tua applicazione cresce, sono state gettate le fondamenta affinché l'architettura non si sgretoli o richieda la distruzione di nuove hack per confondere nuove funzionalità.

Mi rendo conto che quanto sopra sembra un po 'evangelico ma è così che vedo il beneficio di TDD. Anche se puoi creare progetti buoni, solidi e ben architettati usando il TDD, costringi la tua mano a fare le cose nel modo giusto, e poi dimostra che le cose sono fatte bene e, soprattutto, fornisce una linea di base per mantenere le cose giuste. Dal poco che ho imparato in TDD, usarlo mi ha costretto a rendere il codice pulito e seguire i concetti di ingegneria del software, dove altrimenti avrei fatto la "cosa più veloce possibile" che spesso risultava in un incasinato codice "hack".

Posso parlare solo dalla mia esperienza. Per me TDD ha portato diverse cose che non avevo prima nelle mie tool di stile di abitudini di sviluppo. Anche se, vale la pena di dire ancora una volta che TDD non è la soluzione a tutto. Cerco sempre di separare l'esplorazione e l'implementazione pronta per la produzione. Il TDD in fase di esplorazione non è assolutamente necessario e sta addirittura rallentando. Dall'altro lato, per il codice pronto per la produzione, offre numerosi vantaggi che, a breve ea lungo termine, sono molto preziosi per la salute mentale degli sviluppatori e il karma del progetto.

• TDD mi fa pensare prima di implementare, che di solito è una pratica molto buona che impedisce molte riprese e dimentica le soluzioni
• Mi fa pensare in piccole porzioni di problemi, costringendomi a scomporre la soluzione in piccoli pezzi che si adattano insieme.
• Mi fa scrivere codice molto disaccoppiato perché ogni volta che devo mozzare / deridere / fingere qualcosa che non rientra nel problema, naturalmente lancio un "WTF, perché dovrei farlo se non devo essere accoppiato con esso". E mi fa capire meglio le connessioni tra le cose.
• Mi dà una serie di controlli facilmente eseguibili per il mio codice, quindi non devo passare attraverso il doloroso stile "var_dump", "p", "pp", "echo" del debug del codice. Segnala solo cosa è sbagliato, quando è sbagliato. E se non ho ancora un controllo, è solo questione di aggiungere un semplice test per controllarlo più e più volte.
• Mi rende certo che il mio codice funzioni se tutti i test passano prima della distribuzione. Poi, invece di mangiarmi le unghie, vado a mangiare una torta e bevo caffè e mi godo i pomeriggi.
• I test di alto livello sono molto belli nei casi in cui devi refactoring qualcosa. Se il mio modulo deve fornire alcune funzionalità al mondo esterno e ho sviluppato test funzionali / di integrazione / cetriolo per dimostrare che funziona correttamente, sarò molto coraggioso nel rifattorizzare il codice. Diverse volte mi sono trovato di fronte al codice che non ha avuto test e ho bisogno di refactoring. In quel caso c'erano due modi per andare in pratica. 1) rilascia il codice 2) salta le modifiche e lascialo come è.

C'è una cosa che TDD non risolve. Se non sai come costruire la cosa che stai costruendo, allora TDD non produrrà soluzioni per te. È necessario avere un "design" approssimativo o una panoramica del problema e della soluzione. TDD ti farà semplicemente implementare in modo più elegante e manutenibile con il codice di maggiore qualità.

Infine, preferisco pensare in termini di BDD che si basano su pratiche TDD. BDD mi consente di implementare una soluzione utilizzando il vocabolario del dominio e di rendere il software più adatto al problema.

Ci possono essere molti modi per ottenere un grande design, e ci sono indiscutibilmente molte diverse interpretazioni di ciò che costituisce "grande" - o anche "buono". Sospetto che la maggior parte dei TDDers non sarebbe d'accordo con te sulla definizione: se dovessimo guardare il codice che ritieni ottimo, lo considereremmo meno che eccezionale. Il TDD ci spinge ad alcune qualità molto specifiche, e queste qualità si trovano raramente nel codice non TDD.

La testabilità, ovviamente, è una di quelle qualità e quella dominante. I metodi e le classi estremamente piccoli sono forse una sub-caratteristica, e questo porta ad una denominazione eccellente. Forse conosci i programmatori che ottengono queste qualità senza fare TDD, ma io no.