TDD dengan sumber daya terbatas


13

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?


untuk apa LOB berdiri? Bidang usaha?
nyamuk

Jawaban:


14

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.


2
+1: ini bukan tentang menghemat waktu pengembangan, ini menghemat (banyak!) Waktu debugging dan perawatan.
Javier

4
"Jika menurut Anda tes-pertama itu mahal, coba debug-nanti"
Ryan Bigg

@Ryan Bigg: Saya setuju bahwa unit test adalah dukungan hebat untuk debugging tetapi kode yang ditulis dengan baik benar-benar tidak sulit untuk di-debug dengan debugger tradisional.
Giorgio

@Giorgio: kode dapat ditulis sebaik mungkin, ketika Anda tidak dapat mengujinya secara terpisah karena infrastruktur yang hilang di sekitar kode itu, siklus pengujian / debug / perubahan / pengujian lagi hanya membutuhkan waktu lebih lama. Itu secara khusus benar ketika Anda mencari bug di mana Anda tidak tahu akar penyebabnya, dan Anda tidak tahu di mana di baris 100K Anda dari kode yang ditulis dengan baik kegagalan mungkin.
Doc Brown

10

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.

Saya akan menjawab, tetapi Pierre mengatakannya dengan baik. Mulailah dari yang kecil, pada sesuatu yang harus Anda bangun, dan Anda harus memulai manfaatnya di hari pertama.
Marcie

2
Itu mungkin juga bukan ilusi. Latihan baru dapat berlangsung beberapa saat untuk mendapatkan putaran. Apalagi jika tidak ada orang lain di sekitar yang telah melakukannya. Saya akan mengatakan itu bisa berjalan baik secara awal.
dietbuddha

@ Dietbuddha: Saya setuju dengan itu, saya ragu-ragu untuk menempatkan beberapa disclaimer, tapi saya ingin menekankan manfaat nyata pada TDD ketika diterapkan dengan baik.

1
@Pierre - TDD tampaknya memiliki langkah pertama yang sangat jahat (dan saya berbicara dari perjuangan berulang untuk memulai) setelah menderita masalah yang sama yaitu terlalu banyak yang harus dilakukan dan terlalu sedikit waktu. Saya tidak perlu diyakinkan tentang manfaatnya - tetapi bootstrap sendiri dan kemudian rekan-rekan saya saat ini di luar saya (Anda harus percaya bahwa itu bukan kurangnya kemampuan di pihak saya ...) - sebagian karena tekanan dari waktu dan sebagian karena tidak tahu caranya.
Murph

1
@Murph: Apakah Anda bekerja pada aplikasi intensives UI? Saya cenderung berhenti menggunakannya ketika saya mengerjakan aplikasi semacam itu.

8

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.


1
kesalahpahaman umum, TDD menghasilkan tes proyek. Kenyataannya adalah TDD menghasilkan spesifikasi proyek.
Nama Tampilan

3

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.

Seni mencakup Unit Testing


1

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.


1

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.


1
Satu tambahan: Awalnya, cari tes nilai tertinggi. Tes yang memberi tahu Anda, awal, Anda telah merusak basis kode Anda. Ini cenderung tinggi, tes menyapu yang tidak memberi tahu Anda apa yang Anda rusak, tetapi bahwa Anda memecahkannya. Anda akan dengan cepat melihat nilai CI, dengan pengujian, lingkungan. Gunakan tes untuk debug kerusakan. Dengan sistem yang ada, biaya untuk menambahkan tes baru mulai lebih mudah / lebih murah dan Anda dapat fokus pada lebih banyak tes yang melakukan pekerjaan yang lebih baik untuk membuktikan bahwa tes itu bekerja dan menunjukkan di mana tidak.
Jim Rush

0

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! ")

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.