Pendekatan "tulis tes + refactor sampai lulus" terlihat sangat anti-rekayasa.
Anda tampaknya memiliki kesalahpahaman tentang refactoring dan TDD.
Refactoring kode adalah proses mengubah kode sumber program komputer tanpa mengubah perilaku fungsional eksternalnya untuk meningkatkan beberapa atribut nonfungsional dari perangkat lunak.
Dengan demikian Anda tidak dapat refactor kode sampai lolos.
Dan TDD, khususnya pengujian unit (yang saya anggap sebagai peningkatan inti, karena tes lain tampaknya agak masuk akal bagi saya), bukan tentang mendesain ulang komponen hingga berfungsi. Ini adalah tentang mendesain komponen dan bekerja pada implementasi hingga komponen berfungsi seperti yang dirancang.
Penting juga untuk benar-benar memahami, bahwa pengujian unit adalah tentang pengujian unit . Karena kecenderungan untuk selalu menulis banyak hal dari awal, penting untuk menguji unit tersebut. Seorang insinyur sipil sudah mengetahui spesifikasi unit yang ia gunakan (bahan yang berbeda) dan dapat mengharapkan mereka bekerja. Ini adalah dua hal yang sering tidak berlaku untuk insinyur perangkat lunak, dan sangat pro-teknik untuk menguji unit sebelum menggunakannya, karena itu berarti menggunakan komponen yang teruji dan berkualitas tinggi.
Jika seorang insinyur sipil mempunyai ide untuk menggunakan beberapa jaringan serat baru untuk membuat atap untuk menutupi stadion, Anda akan mengharapkan dia untuk mengujinya sebagai satu unit, yaitu mendefinisikan spesifikasi yang diperlukan (misalnya berat, permeabilitas, stabilitas, dll.) Dan setelah itu uji dan sempurnakan sampai bertemu mereka.
Itu sebabnya TDD berfungsi. Karena jika Anda membuat perangkat lunak dari unit yang diuji, kemungkinannya jauh lebih baik, ketika Anda menyambungkannya dan jika tidak, Anda dapat mengharapkan masalah ada dalam kode lem Anda, dengan asumsi tes Anda memiliki cakupan yang baik.
sunting:
Refactoring berarti: tidak ada perubahan fungsi. Satu poin dari pengujian unit penulisan adalah untuk memastikan, bahwa refactoring tidak melanggar kode. Jadi TDD dimaksudkan untuk memastikan, bahwa refactoring tidak memiliki efek samping.
Granularitas bukan subjek perspektif, karena seperti yang saya katakan, unit menguji unit tes dan bukan sistem, di mana granularitas didefinisikan secara tepat.
TDD mendorong arsitektur yang baik. Ini mengharuskan Anda untuk mendefinisikan dan mengimplementasikan spesifikasi untuk semua unit Anda, memaksa Anda untuk mendesainnya sebelum implementasi, yang sangat bertentangan dengan apa yang tampaknya Anda pikirkan. TDD menentukan pembuatan unit, yang dapat diuji secara individual dan dengan demikian sepenuhnya dipisahkan.
TDD tidak berarti saya melakukan tes perangkat lunak pada kode spaghetti dan mengaduk pasta sampai habis.
Dalam kontradiksi dengan teknik sipil, dalam rekayasa perangkat lunak suatu proyek biasanya terus berkembang. Dalam teknik sipil, Anda memiliki persyaratan untuk membangun jembatan di posisi A, yang dapat mengangkut x ton dan cukup lebar untuk n kendaraan per jam.
Dalam rekayasa perangkat lunak, pelanggan pada dasarnya dapat memutuskan pada titik mana pun (mungkin setelah selesai), ia menginginkan jembatan berlipat ganda, dan bahwa ia ingin jembatan itu terhubung dengan jalan raya terdekat, dan bahwa ia ingin jembatan itu menjadi jembatan pengangkat, karena perusahaannya Baru-baru ini mulai menggunakan kapal layar.
Insinyur perangkat lunak ditugaskan untuk mengubah desain. Bukan karena desain mereka cacat, tetapi karena itu adalah modus operandi. Jika perangkat lunak direkayasa dengan baik, maka dapat dirancang ulang pada level tinggi, tanpa harus menulis ulang semua komponen level rendah.
TDD adalah tentang membangun perangkat lunak dengan komponen yang diuji secara terpisah dan sangat terpisah. Dikelola dengan baik, ini akan membantu Anda untuk menanggapi perubahan persyaratan secara signifikan lebih cepat dan lebih aman, daripada tanpa.
TDD menambahkan persyaratan untuk proses pengembangan, tetapi tidak melarang metode jaminan kualitas lainnya. Memang, TDD tidak menyediakan keamanan yang sama dengan verifikasi formal, tetapi sekali lagi, verifikasi formal sangat mahal dan tidak mungkin digunakan pada tingkat sistem. Dan tetap, jika Anda mau, Anda bisa menggabungkan keduanya.
TDD juga mencakup pengujian selain pengujian unit, yang dilakukan pada tingkat sistem. Saya menemukan ini mudah untuk dijelaskan tetapi sulit untuk dieksekusi dan sulit untuk diukur. Juga, mereka cukup masuk akal. Sementara saya benar-benar melihat kebutuhan mereka, saya tidak benar-benar menghargai mereka sebagai ide.
Pada akhirnya, tidak ada alat yang benar-benar memecahkan masalah. Alat hanya mempermudah penyelesaian masalah. Anda dapat bertanya: Bagaimana pahat akan membantu saya dengan arsitektur yang hebat? Nah jika Anda berencana untuk melakukan dinding lurus, batu bata lurus sangat membantu. Dan ya, memang, jika Anda memberikan alat itu kepada orang idiot, ia mungkin akan membantingnya melalui kakinya pada akhirnya, tapi itu bukan kesalahan pahat, sebanyak itu bukan cacat TDD yang memberikan keamanan palsu kepada pemula, yang tidak menulis tes yang bagus.
Jadi pada intinya, dapat dikatakan TDD bekerja jauh lebih baik daripada tanpa TDD.