Apakah pengembangan berbasis tes memaksa saya untuk mengikuti SOLID?

Saya mendengar banyak dari praktisi TDD bahwa salah satu keuntungan TDD adalah memaksa pengembang untuk mengikuti prinsip-prinsip SOLID (Tanggung jawab tunggal, Open-closed, substitusi Liskov, segregasi Antarmuka, dan inversi Ketergantungan). Tetapi bagi saya itu cukup dengan hanya menulis beberapa tes (terutama tes unit) untuk memahami adalah penting untuk mengikuti SOLID (dan dengan demikian membuat arsitektur yang dapat diuji).

Apakah TDD memaksa pengembang untuk mengikuti SOLID lebih aktif daripada hanya menulis tes unit?

Pertama-tama, TDD tidak memaksa Anda untuk menulis kode SOLID. Anda dapat melakukan TDD dan membuat satu kekacauan besar jika Anda mau.

Tentu saja, mengetahui prinsip-prinsip SOLID membantu, karena jika tidak, Anda mungkin berakhir tidak memiliki jawaban yang baik untuk banyak masalah Anda, dan karenanya menulis kode yang buruk disertai dengan tes yang buruk.

Jika Anda sudah tahu tentang prinsip-prinsip SOLID, TDD akan mendorong Anda untuk memikirkannya dan menggunakannya secara aktif.

Yang mengatakan, itu tidak harus mencakup semua huruf dalam SOLID , tetapi sangat mendorong dan mempromosikan Anda untuk menulis setidaknya sebagian kode SOLID, karena itu membuat konsekuensi dari tidak melakukannya segera terlihat dan mengganggu.

Sebagai contoh:

1. Anda harus menulis kode yang dipisahkan sehingga Anda dapat mengejek apa yang Anda butuhkan. Ini mendukung Prinsip Ketergantungan Inversi .
2. Anda perlu menulis tes yang jelas dan singkat sehingga Anda tidak perlu mengubah terlalu banyak dalam tes (yang dapat menjadi sumber kebisingan kode yang besar jika dilakukan sebaliknya). Ini mendukung Prinsip Tanggung Jawab Tunggal .
3. Ini mungkin diperdebatkan, tetapi Prinsip Segregasi Antarmuka memungkinkan kelas untuk bergantung pada antarmuka yang lebih ringan yang membuat ejekan lebih mudah diikuti dan dipahami, karena Anda tidak perlu bertanya "Mengapa 5 metode ini tidak diejek juga?", Atau bahkan yang lebih penting, Anda tidak punya banyak pilihan ketika memutuskan metode mana yang harus diejek. Ini bagus ketika Anda tidak benar-benar ingin membahas seluruh kode kelas sebelum Anda mengujinya, dan gunakan saja trial and error untuk mendapatkan pemahaman dasar tentang cara kerjanya.

Mematuhi prinsip Terbuka / Tertutup mungkin membantu tes yang ditulis setelah kode, karena biasanya memungkinkan Anda untuk mengesampingkan panggilan layanan eksternal di kelas uji yang berasal dari kelas yang diuji. Dalam TDD saya percaya ini tidak diperlukan seperti prinsip lain, tapi saya mungkin salah.

Mengikuti aturan substitusi Liskov sangat bagus jika Anda ingin meminimalkan perubahan untuk kelas Anda untuk menerima contoh yang tidak didukung yang kebetulan menerapkan antarmuka yang diketik secara statis yang sama, tetapi kemungkinan tidak akan terjadi dalam kasus uji yang tepat karena Anda umumnya tidak akan lulus dari setiap kelas-menguji implementasi dunia nyata dari dependensinya.

Yang paling penting, prinsip-prinsip SOLID dibuat untuk mendorong Anda untuk menulis kode yang lebih bersih, lebih mudah dipahami dan dipelihara, dan begitu juga TDD. Jadi, jika Anda melakukan TDD dengan benar, dan Anda memperhatikan bagaimana kode dan pengujian Anda terlihat (dan itu tidak terlalu sulit karena Anda mendapatkan umpan balik langsung, API, dan bijak kebenarannya), Anda dapat lebih sedikit khawatir tentang prinsip SOLID, secara umum.

Tidak

TDD dapat membuatnya lebih mudah untuk mengikuti praktik yang baik karena refactoring berkelanjutan, tetapi itu tidak memaksa Anda mengikuti prinsip apa pun. Yang dilakukan adalah memastikan kode yang Anda tulis diuji. Anda dapat mengikuti prinsip apa pun yang Anda suka saat menulis kode untuk memenuhi ujian; atau tidak ada prinsip sama sekali.

Pemahaman saya tentang Prinsip SOLID diperluas oleh urutan besarnya ketika saya mulai melakukan TDD. Segera setelah saya mulai berpikir tentang bagaimana mengolok-olok dependensi saya menyadari hampir setiap komponen dalam basis kode memiliki implementasi alternatif yang potensial. Dan seberapa mudah untuk menguji API publik sederhana.

Ini juga memberikan pemahaman yang lebih kuat tentang sebagian besar pola desain. Terutama Pola Strategi.

Ya : TDD terutama teknik desain yang baik (dan hanya teknik pengujian sekunder). Sangat membantu untuk mencapai prinsip-prinsip yang kuat, meskipun contoh-contoh TDD (patologis) dengan banyak bau kode masih dimungkinkan.

Koneksi antara TDD dan prinsip-prinsip yang solid diperdebatkan (dengan kesimpulan di atas) dalam podcast hanselmin besar ini yang disebut "Test Driven Development is Design - The Last Word on TDD" .