Lo sviluppo basato sui test mi obbliga a seguire SOLID?

Prima di tutto, TDD non si limita a forzare a scrivere codice SOLID. Potresti creare TDD e creare un grande casino se lo desideri.

Ovviamente, la conoscenza dei principi SOLID aiuta, perché altrimenti potresti finire per non avere una buona risposta a molti dei tuoi problemi, e quindi scrivere codice cattivo accompagnato da test non validi.

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

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

Ad esempio:

1. Devi scrivere codice disaccoppiato in modo da poter prendere in giro ciò di cui hai bisogno. Questo supporta il Principio di inversione delle dipendenze .
2. È necessario scrivere test che siano chiari e brevi, in modo da non dover cambiare troppo nei test (che può diventare una grande fonte di rumore di codice se fatto diversamente). Questo 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 più semplice seguire e capire il mocking, perché non devi chiedere "perché non anche questi 5 metodi sono beffati? ", o ancora più importante, non hai molta scelta quando decidi quale metodo usare per deridere. Questo è utile quando non si vuole veramente esaminare l'intero codice della classe prima di testarlo, e basta usare prove ed errori per ottenere una comprensione di base di come funziona.

L'aderenza al principio Aperto / Chiuso può benissimo aiutare i test scritti dopo del codice, perché di solito consente di ignorare le chiamate di servizio esterne nelle classi di test che derivano dalle classi sotto test. In TDD credo che questo non sia richiesto come altri principi, ma potrei sbagliarmi.

L'aderenza alla regola di sostituzione di Liskov è ottima se si desidera minimizzare le modifiche affinché la classe riceva un'istanza non supportata che si appresta ad implementare la stessa interfaccia tipizzata staticamente, ma non è probabile che si verifichi nei casi di test appropriati perché generalmente non passerai a testare in classe le implementazioni del mondo reale delle sue dipendenze.

Soprattutto, sono stati fatti principi SOLIDI per incoraggiarti a scrivere un codice più pulito, più comprensibile e gestibile, così come TDD. Quindi se fai TDD correttamente, e presti attenzione a come appaiono il tuo codice ei tuoi test (e non è così difficile perché ottieni feedback immediati, API e correttezza), puoi preoccuparti meno dei principi SOLID, in generale.

No

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

La mia comprensione dei Principi SOLIDI è cresciuta 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 del codice base aveva una potenziale implementazione alternativa. E quanto è più semplice provare una semplice API pubblica.

Ha anche fornito una comprensione molto più strong 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 test). Aiuta molto a raggiungere i principi solidi, sebbene gli esempi (patologici) di TDD con molti odori di codice siano ancora possibili.

La connessione tra TDD e principi solidi è contestata (con la conclusione sopra) in questo grande podcast di hanselminute chiamato" Test Driven Development is Design - L'ultima parola su TDD ".