Saya bekerja di perusahaan besar, tetapi hanya dengan dua orang tim yang mengembangkan aplikasi LOB desktop. Saya telah meneliti TDD untuk waktu yang cukup lama sekarang, dan meskipun mudah untuk menyadari manfaatnya untuk aplikasi yang lebih besar, saya mengalami kesulitan mencoba membenarkan waktu untuk mulai menggunakan TDD pada skala aplikasi kami.

Saya memahami kelebihannya dalam mengotomatisasi pengujian, meningkatkan rawatan, dll., Tetapi pada skala kami, menulis bahkan pengujian unit dasar untuk semua komponen kami dapat dengan mudah menggandakan waktu pengembangan. Karena kita sudah tidak memiliki tenggat waktu yang ekstrem, saya tidak yakin arah apa yang harus diambil. Sementara praktik-praktik lain seperti pengembangan berulang yang gesit menjadi sempurna sejak itu, saya agak terbebani oleh trade-off produktivitas TDD pada tim kecil.

Apakah keuntungan TDD sepadan dengan waktu pengembangan ekstra pada tim kecil dengan jadwal yang sangat ketat?

Kebenaran yang buruk adalah bahwa pada awalnya itu akan memperlambat Anda . Proses atau praktik baru apa pun membutuhkan waktu untuk meningkat. Dalam pengalaman saya, TDD tidak membayar dengan implementasi awal seperti halnya dengan pemeliharaan, perbaikan bug, dan ekstensi. Saya tahu bagi orang lain ada pembayaran langsung, jadi itu akan tergantung pada gaya pengkodean setiap orang saat ini.

Sementara saya adalah pendukung besar TDD (saya membawanya ke pekerjaan saya saat ini) saya pikir Anda perlu memiliki sedikit ruang bernafas (tenggat waktu / jadwal) untuk mengeksplorasi dan memahami latihan.

Semakin kecil tim Anda, semakin cepat Anda mendapat manfaat dari TDD. Saya telah melihat pembayaran ini dalam ukuran tim dari 6 hingga 3.

Waktu pengembangan ekstra yang Anda bicarakan mungkin ilusi .

Apa yang membuat TDD berbeda dengan pengujian unit standar adalah tidak hanya digunakan untuk melakukan pengujian.

TDD is a new way of developing software. Ini adalah salah satu cara terbaik yang saya tahu.

Karena itu, ini tidak terkait dengan ukuran proyek Anda. Anda akan mengekstrak manfaat dari baris kode pertama .

• itu akan memaksa Anda menyusun kode dengan cara yang lebih mudah untuk dipelihara dan digunakan kembali. Ini mendorong desain perangkat lunak Anda.
• itu akan membuat refactoring cepat, aman dan menyenangkan.
• ini membantu Anda untuk menulis bongkahan fungsi yang lebih kecil yang membuat pelaksanaan tugas lebih mudah.
• biasanya membuat tugas debugging lebih jarang.

kesalahpahaman umum, izinkan saya meneriakkannya:

UJI DI TDD ADALAH UNTUK FITUR

EOM.

Sunting: izinkan saya menguraikan: "menulis ... unit test untuk semua atau komponen kami" adalah pengujian unit , bukan TDD. Saya secara rutin menggunakan TDD pada tim satu orang dengan sukses besar; imbalannya luar biasa.

Ada sebuah buku hebat tentang TDD, The art of unit testing ( situs resmi ) yang memiliki contohnya di .net dengan versi java pada karya-karyanya. Bagian yang baik adalah bahwa ada seluruh bab yang mempertimbangkan masalah-masalah seperti "Mengintegrasikan pengujian unit ke dalam organisasi" - Bab 8 dan "Bekerja dengan kode warisan" - Bab 9. Meskipun saya bukan ahli dalam bidang ini (belum :-)) , berdasarkan pengalaman saya, saya percaya ini adalah titik awal yang baik.

Ada beberapa pertanyaan yang perlu Anda dapatkan jawabannya:

1. Berapa banyak waktu yang Anda habiskan setelah merilis perbaikan bug dalam kode? Jika Anda dapat menghitung ini, Anda mungkin menemukan bahwa itu sama dengan atau bahkan melebihi waktu "ekstra" yang diperlukan untuk Anda menulis tes yang akan membantu mencegah bug ini terjadi.

2. Seberapa sering mengedit yang tampaknya lurus ke depan untuk refactor kode atau menambahkan fitur baru memecahkan sesuatu yang tampaknya tidak terkait? Sekali lagi dengan cakupan tes yang baik ini dapat dikurangi.

Bahkan jika Anda tidak dapat memasukkan angka pasti pada angka-angka ini, Anda harus dapat menunjukkan bahwa Anda menghabiskan waktu ini sehingga Anda mungkin juga membelanjakannya "di muka" dan (mudah-mudahan) berakhir dengan produk yang jauh lebih stabil.

Ketika orang-orang berbicara kepada saya tentang mulai mengadopsi pengujian di tim mereka, saya selalu memeriksa dulu bagaimana tes akan dijalankan. Seringkali tim tidak memiliki pembangunan berkelanjutan di tempat. Jika Anda memiliki sumber daya yang terbatas, maka saya sarankan untuk menyiapkan server CI adalah prasyarat untuk memulai pengujian serius.

Setelah Anda mendapatkan pengaturan itu maka mulailah berlatih TDD. Ingatlah bahwa jika sistem belum dikembangkan dengan pengujian dalam pikiran Anda mungkin berjuang untuk membuat kode yang ada dapat diuji, dan itu akan menjadi mahal untuk merestrukturisasi itu.

Mulailah dengan mencari tempat yang mudah untuk memulai dengan TDD - kelas atau modul baru, dengan sedikit ketergantungan. Kelas utilitas dan struktur data seringkali merupakan hal yang baik untuk memulai.

Rasakan bagaimana hal itu mengubah cara Anda berpikir tentang kode Anda, perhatikan seberapa baik kode yang Anda hasilkan, dan seberapa jauh Anda lebih percaya diri tentang kode itu.

Saya tahu saya belum benar-benar menjawab pertanyaan itu, tetapi saya kira maksud saya adalah Anda harus dapat melakukan semua ini tanpa biaya tambahan yang besar. Dalam mengerjakan contoh pertama Anda, Anda akan lebih memahami manfaat untuk proyek Anda.

Intinya - pengembangan lebih lambat, tetapi sedikit cacat, sehingga waktu perbaikan bug jauh lebih sedikit.

Di sinilah saya pikir Pengembangan Berbasis Perilaku menunjukkan keuntungan langsung, tetapi saya tidak yakin bahwa pengembangan yang digerakkan oleh pengujian akan berhasil.

Dalam pengembangan yang didorong oleh perilaku, Anda mendekati tiket Anda dengan cara yang berbeda: Anda duduk bersama pebisnis dan bekerja dengannya untuk menentukan perilaku yang seharusnya dimiliki oleh sejumlah fungsi ini. Saya menggambarkan ini dalam sebuah entri di blog saya, (judul posting: Perilaku Menulis ).

Duduk bersama pebisnis atau siapa pun akan membantu Anda dan mereka untuk lebih memahami apa yang perlu dilakukan sistem agar semua orang senang dengan fungsi tersebut. Apa yang perlu dilakukan untuk dapat diterima oleh proses QA yang Anda miliki.

Menentukan kriteria pengujian, lalu menuliskan kriteria pengujian itu ke dalam rangkaian pengujian otomatis Anda, akan mengurangi jumlah bolak-balik yang Anda dapatkan: seseorang yang mengklaim fungsionalitasnya rusak, karena Anda melewatkan sesuatu (baik karena Anda melewatkan sesuatu secara sah, atau karena mereka tidak pernah memberi tahu Anda tentang hal itu).

Ini juga dapat membantu persepsi orang lain tentang tim Anda: jika Anda duduk dan menentukan apa yang perlu dilakukan dalam sistem, Anda bisa beralih dari, "orang idiot yang mengubah segalanya dan menghabiskan waktu untuk hal-hal yang tidak kami minta", untuk, "Orang pintar yang datang dengan fitur yang berguna".

TL; DR: Pengembangan Berbasis Perilaku dapat menunjukkan perbaikan dengan cepat karena fokusnya adalah "pelanggan". Test Driven Development, bagi saya, tampaknya tentang pengujian internal basis kode yang "tidak ada yang peduli" dan memberikan manfaat bisnis yang kurang jelas. (Behavior Driven Development memiliki perubahan langsung di wajah Anda: para insinyur tiba-tiba memiliki lebih banyak waktu tatap muka dengan "pelanggan" atau analis bisnis untuk mencoba melakukan hal ini dengan benar - yang seharusnya dilihat sebagai hal yang baik. "Oh , mereka mengadakan rapat tentang Fitur X, yang berarti ada kemajuan di bagian depan itu! ")