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

I guru del TDD ci dicono sempre di più che il TDD non riguarda i test, ma il design . Quindi conosco alcuni sviluppatori che creano un design davvero eccezionale senza TDD. Dovrebbero praticare TDD allora?

TDD non solo mi aiuta a raggiungere il miglior progetto finale, mi aiuta ad arrivarci in meno tentativi.

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

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 di TDD sta davvero cercando di dire non è che TDD è un processo di progettazione (anche se un certo numero di persone lo hanno purtroppo interpretato in quel modo). Il messaggio qui è che l'uso di un processo come TDD, se lo fai nel modo giusto , tenderà a migliorare il tuo design complessivo.

Il concetto fondamentale è molto più antico di TDD; progettando per testabilità . Se aderisci rigorosamente ai principi SOLID , in particolare il principio di responsabilità singola , troverai il codice molto facile da testare. D'altra parte, se tendi ad essere un po 'più sciatto nel tuo design, probabilmente troverai il processo di scrittura di unit test per costringerti a farlo più spesso, per evitare la frustrazione di (a) capire cosa deve essere testato e (b) passare più tempo a impostare dipendenze che a scrivere i test effettivi.

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

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

Ovviamente puoi creare buoni progetti senza mai scrivere un singolo test, ma sei sicuro che siano fantastici progetti? Come fai a sapere se non sono chiaramente indicati dai test? I test scoprono molti problemi e, sebbene un processo di QA possa trovare bug visibili, non scopriranno decisioni di progettazione sbagliate.

Risposta semplicistica proveniente da qualcuno che cerca di imparare il TDD: non ne hai bisogno , ma il vantaggio principale che ti dà è, in parole povere, la fiducia : la sicurezza che la tua applicazione funzioni. Fiducia che i casi d'uso siano soddisfatti. Fiducia che la tua logica è valida per il modulo "Foobar". Fiducia nel fatto che il tuo codice sia strutturato correttamente per essere mantenibile ed estendibile per sei mesi lungo la strada quando il CEO vuole aggiungere alcune nuove funzionalità pazze di cui ha letto. Fiducia nel fatto che, quando la tua applicazione cresce, sono state gettate le basi affinché l'architettura non si disgreghi o richieda gobber di hack disordinati per creare nuove funzionalità della giuria.

Mi rendo conto che quanto sopra sembrava un po 'evangelico ma è così che vedo i benefici del TDD. Anche se è possibile creare progetti validi, solidi e ben progettati utilizzando TDD, si forza la mano nel fare le cose nel modo giusto, e quindi si dimostra che le cose sono fatte nel modo giusto e, soprattutto, fornisce una base per mantenere le cose nel modo giusto. Dal poco che mi sono dilettato in TDD, usarlo mi ha costretto a rendere il codice pulito e seguire i concetti di ingegneria del software corretti, dove altrimenti avrei fatto la "cosa più veloce possibile" che spesso si traduceva in un disordinato codice "hack".

Posso parlare solo per esperienza. Per me TDD ha portato molte cose che non avevo prima nella mia cassetta degli attrezzi delle mie abitudini di sviluppo. Tuttavia, vale la pena ribadire che TDD non è una soluzione a tutto. Cerco sempre di separare l'implementazione pronta per l'esplorazione e la produzione. Il TDD in fase di esplorazione non è assolutamente necessario e sta persino rallentando. Dall'altro lato, il codice pronto per la produzione offre numerosi vantaggi che a breve e 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 è un'ottima pratica che impedisce molte riprese e dimentica le soluzioni
• Mi fa pensare in piccole parti del problema, costringendomi a spezzare la soluzione a piccoli pezzi che si incastrano.
• Mi fa scrivere un codice molto disaccoppiato perché ogni volta che devo stub / deridere / falsificare qualcosa che non si adatta al problema, lancio naturalmente un "WTF, perché dovrei farlo se non devo accoppiarlo 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 "deb_dump", "p", "pp", "echo" del debug del codice. Segnala solo ciò che è sbagliato, quando è sbagliato. E se non ho ancora un controllo, è solo questione di aggiungere semplici test per verificarlo più e più volte.
• Mi rende certo che il mio codice funziona se tutti i test superano la distribuzione. Poi invece di mangiare le unghie vado a mangiare una torta e bere caffè e godermi i miei pomeriggi.
• I test di alto livello sono molto belli nei casi in cui devi refactificare qualcosa. Se il mio modulo deve fornire alcune funzionalità al mondo esterno e ho sviluppato test funzionali / di integrazione / di cetriolo per dimostrare che funziona correttamente, sarò molto coraggioso per rimediare all'inferno da quel codice. Più volte mi sono trovato di fronte al codice che non aveva test e che dovevo refactoring. In quel caso c'erano due modi per andare in pratica. 1) rilasciare il codice 2) saltare le modifiche e lasciarlo così com'è.

C'è una cosa che TDD non risolve. Se non sai come costruire ciò che stai costruendo, TDD non produrrà la soluzione per te. È necessario disporre di una "progettazione" approssimativa o di una panoramica del problema e della soluzione. TDD ti consentirà di implementarlo in modo più elegante e sostenibile con il codice di qualità superiore.

Alla fine, preferisco pensare in termini BDD che si basano sulle pratiche TDD. BDD mi fa implementare una soluzione usando il vocabolario del dominio e per adattare meglio il software al problema.

Ci possono essere molti modi per ottenere un grande design e ci sono senza dubbio molte interpretazioni diverse di ciò che costituisce "grande" - o addirittura "buono". Sospetto che la maggior parte dei TDDer non sia d'accordo con te sulla definizione - che se guardassimo il codice che ritieni ottimo, lo considereremmo meno che eccezionale. TDD ci porta ad alcune qualità molto specifiche e queste qualità si trovano raramente nel codice non TDD.

La testabilità, ovviamente, è una di quelle qualità, e quella generale. Metodi e classi estremamente piccoli sono forse una caratteristica secondaria e ciò porta a una denominazione eccellente. Forse conosci programmatori che ottengono queste qualità senza fare TDD, ma io no.