Seberapa berharganya suatu pendekatan khusus untuk pengujian tergantung pada seberapa kritis misi sistem yang sedang dikembangkan, dan seberapa banyak beberapa sistem kritis misi lainnya bergantung padanya. Skrip buku tamu sederhana untuk situs web Anda hampir tidak dapat dianggap sebagai misi kritis, tetapi jika situs web itu berjalan dapat berpotensi dikompromikan oleh bug yang memungkinkan input tanpa filter ke database dan situs itu menawarkan beberapa layanan penting, maka tiba-tiba itu menjadi jauh lebih banyak. penting untuk skrip buku tamu untuk diuji secara menyeluruh. Hal yang sama juga berlaku untuk kode framework / library. Jika Anda mengembangkan kerangka kerja dengan bug, maka setiap aplikasi yang menggunakan fitur kerangka kerja itu juga memiliki bug yang sama.
Pengembangan yang digerakkan oleh tes memberi Anda lapisan keselamatan tambahan saat melakukan tes. Jika Anda menulis tes di samping atau bahkan setelah kode yang ingin Anda uji, maka ada risiko nyata bahwa Anda salah tes. Jika Anda menulis semua tes terlebih dahulu, lalu bagaimana kode bekerja secara internal tidak dapat memengaruhi apa yang Anda tulis untuk tes, dan oleh karena itu ada sedikit kemungkinan bahwa Anda secara tidak sengaja menulis tes yang berpikir bahwa output yang salah tertentu benar.
Pengembangan yang digerakkan oleh tes juga mendorong pengembang Anda untuk menulis kode yang mudah diuji, karena mereka tidak ingin memberikan lebih banyak pekerjaan kepada diri mereka sendiri! Kode yang mudah diuji cenderung menjadi kode yang mudah dipahami, digunakan kembali, dan dipelihara.
Dan pemeliharaan adalah tempat Anda benar-benar akan menuai hasil TDD. Sebagian besar upaya pemrograman yang dikeluarkan untuk perangkat lunak terkait dengan pemeliharaan. Ini berarti membuat perubahan pada kode langsung untuk memberikan fitur baru, memperbaiki bug, atau menyesuaikannya dengan situasi baru. Saat membuat perubahan seperti itu, Anda ingin memastikan bahwa perubahan yang Anda buat memiliki efek yang diinginkan, dan yang lebih penting, mereka tidak memiliki ketukan efek yang tidak terduga. Jika Anda memiliki rangkaian uji lengkap untuk kode Anda, maka mudah untuk memverifikasi bahwa setiap perubahan yang Anda buat tidak merusak sesuatu yang lain, dan jika perubahan yang Anda lakukan merusak sesuatu yang lain maka Anda dapat dengan cepat menemukan alasannya. Manfaatnya jangka panjang.
Anda mengatakan hal berikut dalam pertanyaan Anda:
Saya melihat beberapa manfaat untuk menulis tes untuk beberapa hal, tetapi sangat sedikit. Dan sementara saya suka ide untuk menulis tes pertama, saya menemukan saya menghabiskan lebih banyak waktu mencoba debug tes saya untuk membuat mereka mengatakan apa yang sebenarnya saya maksudkan daripada saya debugging kode yang sebenarnya. Ini mungkin karena kode tes seringkali jauh lebih rumit daripada kode yang diuji. Saya harap ini hanya pengalaman kurang dengan alat yang tersedia (rspec dalam hal ini).
Ini sepertinya menyarankan kepada saya bahwa Anda tidak cukup mendapatkan pengujian. Tes unit seharusnya sangat sederhana, hanya urutan panggilan metode, diikuti oleh pernyataan untuk membandingkan hasil yang diharapkan dengan hasil yang sebenarnya. Mereka dimaksudkan untuk menjadi sederhana karena bug dalam tes Anda akan menjadi bencana, dan jika Anda memperkenalkan loop, percabangan atau program lain melempar kontrol ke dalam tes, maka kemungkinan besar tes tersebut akan memasukkan bug ke dalamnya. Jika Anda menghabiskan banyak waktu men-debug tes maka itu menunjukkan bahwa tes Anda terlalu rumit dan Anda harus menyederhanakannya.
Jika tes tidak dapat disederhanakan, daripada fakta itu saja menunjukkan bahwa ada sesuatu yang salah dengan kode yang diuji. Sebagai contoh jika kelas Anda memiliki metode yang panjang, metode dengan banyak if / elseif / else atau beralih pernyataan atau sejumlah besar metode yang memiliki interaksi kompleks yang ditentukan oleh keadaan kelas saat ini, maka tes yang diperlukan harus sangat kompleks. untuk memberikan cakupan kode lengkap dan menguji semua kemungkinan. Jika kelas Anda memiliki ketergantungan kode keras pada kelas lain maka ini lagi akan meningkatkan jumlah simpai Anda harus melompat untuk menguji kode Anda secara efektif.
Jika Anda menjaga kelas Anda kecil dan sangat fokus, dengan metode pendek dengan beberapa jalur eksekusi dan mencoba menghilangkan keadaan internal maka tes dapat disederhanakan. Dan ini adalah inti permasalahannya. Kode yang baik pada dasarnya mudah untuk diuji. Jika kodenya tidak mudah untuk diuji, mungkin ada sesuatu yang salah dengannya.
Tes unit menulis adalah sesuatu yang bermanfaat bagi Anda dalam jangka panjang, dan menghindarinya hanyalah menyimpan masalah untuk nanti. Anda mungkin tidak terbiasa dengan konsep utang teknis, tetapi ini sangat mirip dengan utang finansial. Tidak menulis tes, tidak berkomentar kode, menulis dalam dependensi kode keras dan sebagainya adalah cara-cara masuk ke hutang. Anda "meminjam" waktu dengan mengambil jalan pintas sejak dini dan ini mungkin membantu Anda mencapai tenggat waktu yang ketat, tetapi waktu yang Anda hemat sebelumnya dalam proyek adalah pinjaman. Setiap hari berlalu tanpa membersihkan kode, mengomentari dengan benar, atau membangun test suite akan membuat Anda tertarik. Semakin lama berlangsung, semakin banyak bunga terakumulasi. Akhirnya, Anda akan menemukan kode Anda telah menjadi kekacauan kusut yang tidak dapat Anda ubah tanpa memicu konsekuensi yang tidak diinginkan.
Anda dapat berpikir untuk menulis unit test lebih awal dan menjadikannya terbaru sebagai bentuk "kredit teknis". Anda menempatkan waktu di bank dengan membelanjakannya di awal proyek untuk mengikuti praktik yang baik. Anda akan mendapatkan bunga pada tinjauan ke depan ini nanti ketika Anda sampai ke fase pemeliharaan proyek. Ketika Anda ingin melakukan perubahan, Anda dapat dengan mudah memvalidasi kebenaran perubahan dan bahwa itu tidak memiliki efek samping yang tidak diinginkan, dan Anda bisa mendapatkan pembaruan keluar pintu dengan cepat dan tanpa keributan. Jika bug muncul, Anda dapat menambahkan unit test baru yang melatih bug, lalu perbaiki bug dalam kode. Ketika berikutnya Anda menjalankan unit test Anda akan dapat memverifikasi bahwa bug telah diperbaiki, dan bahwa itu tidak menyebabkan masalah lain. Lebih jauh lagi, Anda akan menghindari "regresi",
TL: DR - Ya, mereka adalah bantuan dunia nyata, tetapi mereka adalah investasi. Manfaatnya baru terlihat kemudian.