Lo sviluppo guidato dai test mi costringe a seguire SOLID?

Ho sentito molto dai professionisti di TDD che uno dei vantaggi di TDD è che costringe gli sviluppatori a seguire i principi SOLID (responsabilità singola, Open-closed, sostituzione di Liskov, segregazione dell'interfaccia e inversione di dipendenza). Ma per quanto mi riguarda basta scrivere alcuni test (principalmente test unitari) per capire che è importante seguire SOLID (e quindi creare un'architettura testabile).

TDD obbliga gli sviluppatori a seguire SOLID più attivamente della semplice scrittura di unit test?

Prima di tutto, TDD non ti obbliga a scrivere codice SOLID. Potresti fare TDD e creare un grande casino se lo desideri.

Naturalmente, conoscere i principi SOLID aiuta, perché altrimenti potresti semplicemente non avere una buona risposta a molti dei tuoi problemi, e quindi scrivere codici errati accompagnati da test errati.

Se conosci già i principi SOLID, TDD ti incoraggerà a pensarci e ad usarli attivamente.

Detto questo, non copre necessariamente tutte le lettere in SOLID , ma ti incoraggia fortemente e ti promuove a scrivere almeno in parte il codice SOLID, perché rende le conseguenze di non farlo immediatamente visibili e fastidiose.

Per esempio:

1. Devi scrivere il codice disaccoppiato in modo da poter deridere ciò di cui hai bisogno. Questo supporta il principio di inversione di dipendenza .
2. È necessario scrivere test chiari e brevi in ​​modo da non dover cambiare troppo nei test (che può diventare una grande fonte di rumore del codice se fatto diversamente). Ciò supporta il principio di responsabilità singola .
3. Questo può essere discusso, ma il principio di segregazione dell'interfaccia consente alle classi di dipendere da interfacce più leggere che rendono il deridere più facile da seguire e da capire, perché non devi chiedere "Perché non sono stati derisi anche questi 5 metodi?", Oppure ancora più importante, non hai molta scelta quando decidi quale metodo prendere in giro. Questo è utile quando non vuoi davvero esaminare l'intero codice della classe prima di testarlo, e usa semplicemente tentativi ed errori per avere una comprensione di base di come funziona.

L'adesione al principio Open / Closed può aiutare i test scritti dopo il codice, poiché in genere consente di ignorare le chiamate di servizio esterne nelle classi di test che derivano dalle classi sotto test. Nel TDD credo che questo non sia richiesto come altri principi, ma potrei sbagliarmi.

L'adesione alla regola di sostituzione di Liskov è ottima se si desidera ridurre al minimo le modifiche affinché la classe riceva un'istanza non supportata che capita solo di implementare la stessa interfaccia di tipo statico, ma non è probabile che accada in casi di test appropriati perché si è generalmente non passerà nessuna classe sotto test alle implementazioni reali delle sue dipendenze.

Ancora più importante, i principi SOLID sono stati creati per incoraggiarti a scrivere codice più pulito, più comprensibile e gestibile, e così è stato TDD. Quindi, se esegui TDD correttamente e presti attenzione all'aspetto del tuo codice e dei tuoi test (e non è così difficile perché ottieni feedback immediati, API e correttezza saggia), puoi preoccuparti di meno dei principi SOLID, in generale.

No

TDD può rendere più semplice seguire le buone pratiche a causa del continuo refactoring, ma non ti obbliga a seguire alcun principio. Tutto ciò che fa è assicurarsi che il codice che scrivi sia testato. Puoi seguire qualunque principio ti piaccia quando scrivi il codice per soddisfare il test; o nessun principio.

La mia comprensione dei Principi SOLID si è ampliata di un ordine di grandezza quando ho iniziato a fare TDD. Non appena ho iniziato a pensare a come deridere le dipendenze mi sono reso conto che praticamente ogni componente nella base di codice aveva un'implementazione alternativa potenziale. E quanto è più facile testare una semplice API pubblica.

Ha inoltre fornito una comprensione molto più forte della maggior parte dei modelli di progettazione. Soprattutto il modello di strategia.

Sì : TDD è principalmente una buona tecnica di progettazione (e solo secondaria una tecnica di prova). Aiuta molto a raggiungere i solidi principi, sebbene siano ancora possibili esempi (patologici) di TDD con molti odori di codice.

La connessione tra TDD e i solidi principi è contestata (con la conclusione sopra) in questo grande podcast hanselminute chiamato "Test Driven Development is Design - The Last Word on TDD" .