Pengujian unit terdengar hebat bagi saya, tetapi saya tidak yakin saya harus menghabiskan waktu benar-benar mempelajarinya kecuali saya dapat meyakinkan orang lain yang memiliki nilai signifikan. Saya harus meyakinkan programmer lain dan, yang lebih penting, penghitung kacang dalam manajemen, bahwa semua waktu ekstra yang dihabiskan untuk mempelajari kerangka pengujian, menulis tes, menjaga mereka diperbarui, dll. Akan membayar untuk dirinya sendiri, dan kemudian beberapa.

Apa buktinya? Adakah yang benar-benar mengembangkan perangkat lunak yang sama dengan dua tim yang terpisah, satu menggunakan unit testing dan yang lainnya tidak, dan membandingkan hasilnya? Aku meragukan itu. Apakah saya seharusnya membenarkannya dengan, "Cari di Internet, semua orang membicarakannya, jadi itu pasti hal yang benar untuk dilakukan"?

Di mana bukti kuat yang akan meyakinkan orang awam bahwa pengujian unit layak dilakukan?

Iya. Ini adalah tautan ke studi oleh Boby George dan Laurie Williams di NCST dan lainnya oleh Nagappan et al. Saya yakin masih ada lagi. Publikasi Dr. Williams tentang pengujian dapat memberikan titik awal yang baik untuk menemukannya.

[EDIT] Dua makalah di atas secara khusus mereferensikan TDD dan menunjukkan peningkatan 15-35% pada waktu pengembangan awal setelah mengadopsi TDD, tetapi penurunan 40-90% pada cacat pra-rilis. Jika Anda tidak bisa mendapatkan versi teks lengkap, saya sarankan menggunakan Google Cendekia untuk melihat apakah Anda dapat menemukan versi yang tersedia untuk umum.

"Saya harus memberi tahu pemrogram lain dan, yang lebih penting, penghitung kacang dalam manajemen, bahwa semua waktu ekstra yang dihabiskan untuk mempelajari kerangka pengujian, menulis tes, menjaga mereka diperbarui, dll. Akan membayar sendiri, dan kemudian beberapa. "

Mengapa?

Mengapa tidak lakukan saja, dengan diam-diam dan dengan hati-hati. Anda tidak harus melakukannya sekaligus. Anda dapat melakukan ini dalam potongan kecil kecil.

Pembelajaran kerangka kerja membutuhkan waktu yang sangat sedikit.

Menulis satu tes, hanya satu, membutuhkan sedikit waktu.

Tanpa pengujian unit, yang Anda miliki adalah kepercayaan pada perangkat lunak Anda. Dengan satu tes unit, Anda masih memiliki kepercayaan diri Anda, ditambah bukti bahwa setidaknya satu tes lolos.

Hanya itu yang dibutuhkan. Tidak ada yang perlu tahu Anda melakukannya. Lakukan saja.

Saya mengambil pendekatan berbeda untuk ini:

Jaminan apa yang Anda miliki bahwa kode Anda benar? Atau itu tidak melanggar asumsi X ketika seseorang di tim Anda mengubah func1 ()? Tanpa tes unit membuat Anda 'jujur', saya tidak yakin Anda memiliki banyak jaminan.

Gagasan menjaga agar tes diperbarui selalu menarik. Tes itu sendiri tidak sering harus berubah. Saya mendapat 3x kode uji dibandingkan dengan kode produksi, dan kode uji telah diubah sangat sedikit. Namun, inilah yang memungkinkan saya tidur nyenyak di malam hari dan hal yang memungkinkan saya untuk memberi tahu pelanggan bahwa saya memiliki keyakinan bahwa saya dapat mengimplementasikan fungsi Y tanpa merusak sistem.

Mungkin di dunia akademis ada buktinya, tetapi saya tidak pernah bekerja di dunia komersial di mana ada orang yang mau membayar untuk tes semacam itu. Saya dapat memberitahu Anda, bagaimanapun, bahwa itu bekerja dengan baik untuk saya, butuh sedikit waktu untuk terbiasa dengan kerangka pengujian dan tes menulis membuat saya benar-benar memikirkan persyaratan dan desain saya, jauh lebih banyak daripada yang pernah saya lakukan ketika bekerja pada tim yang menulis tidak ada tes.

Di sinilah ia membayar untuk dirinya sendiri: 1) Anda memiliki kepercayaan diri pada kode Anda dan 2) Anda menangkap masalah lebih awal dari yang seharusnya. Anda tidak memiliki orang QA mengatakan "hei, Anda tidak repot-repot memeriksa fungsi xyz (), kan? Dia tidak bisa menemukan bug itu karena Anda menemukannya sebulan yang lalu. Itu bagus untuk dia, bagus untukmu, bagus untuk perusahaan dan bagus untuk pelanggan

Jelas ini adalah anekdotal, tetapi itu telah berhasil bagi saya. Tidak yakin saya bisa memberi Anda spreadsheet, tetapi pelanggan saya senang dan itu adalah tujuan akhir.

Kami telah menunjukkan dengan bukti kuat bahwa mungkin untuk menulis perangkat lunak jelek tanpa Unit Testing. Saya percaya bahkan ada bukti untuk perangkat lunak jelek dengan Unit Testing. Tapi ini bukan intinya.

Unit Testing atau Test Driven Development (TDD) adalah teknik Desain, bukan teknik pengujian. Kode yang digerakkan oleh tes tertulis terlihat sangat berbeda dari kode yang tidak.

Meskipun ini bukan pertanyaan Anda, saya ingin tahu apakah ini benar-benar cara termudah untuk pergi dan menjawab pertanyaan (dan membawa bukti yang mungkin ditantang oleh laporan lain) yang mungkin ditanyakan salah. Bahkan jika Anda menemukan bukti kuat untuk kasus Anda - orang lain mungkin menemukan bukti keras untuk dilawan.

Apakah ini bisnis penghitung kacang untuk menentukan bagaimana orang teknis harus bekerja? Apakah mereka menyediakan alat termurah dalam semua kasus karena mereka percaya Anda tidak membutuhkan yang lebih mahal?

Argumen ini dimenangkan berdasarkan kepercayaan (salah satu nilai dasar dari tim lincah) atau hilang berdasarkan kekuatan peran dari pihak yang menang. Bahkan jika pendukung TDD menang berdasarkan kekuatan peran, saya akan menghitungnya sebagai hilang.

Jika Anda juga tertarik pada bukti terhadap pengujian unit di sini adalah salah satu artikel yang diteliti dan dipikirkan dengan baik:

Mengapa Sebagian Besar Unit Pengujian adalah Pemborosan Oleh James O Coplien (guru lean dan lincah)

Lebih lanjut tentang TDD daripada pengujian unit semata, berikut ini tautan ke Mewujudkan peningkatan kualitas melalui pengembangan yang digerakkan oleh tes: hasil dan pengalaman empat makalah tim industri , oleh Nagappan, E. Michael Maximilien, Thirumalesh Bhat, dan Laurie Williams. makalah yang diterbitkan oleh kelompok Rekayasa Perangkat Lunak dan Pengukuran Microsoft (ESM) dan telah disebutkan di sini.

Tim menemukan bahwa tim TDD menghasilkan kode yang antara 60% dan 90% lebih baik (dalam hal kepadatan cacat) daripada tim non-TDD. Namun tim TDD membutuhkan waktu antara 15% dan 35% lebih lama untuk menyelesaikan proyek mereka.

Ini bacaan yang bagus dan menghibur tentang seorang pria yang mengubah perusahaannya dari dalam. Ini tidak terbatas pada TDD. http://jamesshore.com/Change-Diary/ Perhatikan bahwa dia tidak membujuk "penghitung kacang" untuk beberapa waktu dan melakukan "taktik gerilya" sebagai gantinya.

Hanya untuk menambahkan lebih banyak informasi ke jawaban ini, ada dua sumber daya meta-analisis yang dapat membantu mencari tahu efek produktivitas & kualitas pada latar belakang akademik dan industri:

Pengantar Editor Tamu: TDD — Seni Pemrograman Tak Takut [ tautan ]

Semua peneliti tampaknya setuju bahwa TDD mendorong fokus tugas dan cakupan tes yang lebih baik. Fakta lebih banyak tes tidak selalu berarti bahwa kualitas perangkat lunak akan lebih baik, tetapi peningkatan perhatian programmer terhadap desain pengujian tetap menggembirakan. Jika kami melihat pengujian sebagai sampel populasi yang sangat besar dari perilaku potensial, lebih banyak tes berarti sampel yang lebih menyeluruh. Sejauh setiap tes dapat menemukan masalah penting yang tidak dapat ditemukan oleh yang lain, tes ini berguna, terutama jika Anda dapat menjalankannya dengan murah.

Tabel 1. Ringkasan studi empiris terpilih dari pengembangan berbasis tes: peserta industri *

Tabel 2. Ringkasan studi empiris terpilih dari TDD: peserta akademik *

Pengaruh Pengembangan yang Didorong oleh Uji pada Kualitas dan Produktivitas Eksternal: A Meta-Analysis [ tautan ]

Abstrak:

Makalah ini memberikan meta-analisis sistematis dari 27 studi yang menyelidiki dampak Test-Driven Development (TDD) pada kualitas dan produktivitas kode eksternal.

Hasil menunjukkan bahwa, secara umum, TDD memiliki efek positif kecil pada kualitas tetapi sedikit atau tidak ada efek nyata pada produktivitas. Namun, analisis subkelompok telah menemukan peningkatan kualitas dan penurunan produktivitas jauh lebih besar dalam studi industri dibandingkan dengan studi akademik. Penurunan produktivitas yang lebih besar ditemukan dalam penelitian di mana perbedaan dalam upaya uji antara TDD dan proses kelompok kontrol adalah signifikan. Peningkatan kualitas yang lebih besar juga ditemukan dalam studi akademik ketika perbedaan dalam upaya tes sangat besar; Namun, tidak ada kesimpulan yang dapat diambil mengenai studi industri karena kurangnya data.

Akhirnya, pengaruh pengalaman pengembang dan ukuran tugas sebagai variabel moderator diselidiki, dan korelasi positif yang signifikan secara statistik ditemukan antara ukuran tugas dan besarnya peningkatan kualitas.

Nah, ada beberapa perusahaan besar yang mengharuskan Anda menggunakan unit testing tetapi jika Anda adalah perusahaan kecil mengapa meniru perusahaan besar?

Bagi saya ketika saya mulai dengan pengujian unit, bertahun-tahun yang lalu, (hari ini kami lebih banyak menggunakan model perilaku ) itu karena saya tidak bisa mengendalikan semua jalur dalam satu aplikasi.

Saya sudah terbiasa dengan pemrograman bawah pertama dan REPL jadi ketika saya mendapat Uji Unit (Satu Tes untuk Setiap Fungsi) itu seperti membawa kembali REPL ke bahasa yang sangat kompilasi. Itu membawa kesenangan kembali ke setiap baris kode yang saya tulis. Saya merasa tuhan. Aku menyukainya. Saya tidak perlu laporan untuk memberi tahu saya bahwa saya mulai menulis kode yang lebih baik lebih cepat. Bos saya tidak perlu laporan untuk memperhatikan bahwa karena kami melakukan hal-hal gila kami tiba-tiba tidak pernah melewatkan tenggat waktu. Bos saya tidak memerlukan laporan untuk memperhatikan bahwa jumlah bug "biasa" turun dari (ke banyak) menjadi hampir nol karena hal yang sangat aneh dalam penulisan kode non-produktif ini.

Seperti yang sudah ditulis oleh poster lain, Anda tidak menggunakan TDD untuk Menguji (memverifikasi). Anda menulisnya untuk menangkap spesifikasi, perilaku dari apa yang unit Anda (objek, modul, fungsi, kelas, server, kluster) bekerja.

Ada banyak kegagalan dan kisah sukses beralih ke model pengembangan perangkat lunak yang berbeda di banyak perusahaan.

Saya baru mulai menggunakannya kapan pun saya punya sesuatu yang baru untuk ditulis. Ada pepatah lama yang agak sulit bagi saya untuk menerjemahkan ke bahasa Inggris tetapi:

Mulailah dengan sesuatu yang sangat sederhana sehingga Anda tidak menyadari bahwa Anda melakukannya. Saat berlatih maraton, mulailah dengan berjalan 9 meter dan lari 1 meter, ulangi.

Ada statistik yang membuktikan bahwa memperbaiki bug yang ditemukan dalam tes unit / integrasi berkali-kali lebih murah daripada memperbaiki begitu ada pada sistem live (mereka didasarkan pada pemantauan ribuan proyek kehidupan nyata).

Sunting : misalnya, seperti yang ditunjukkan, buku " Kode Lengkap " melaporkan studi tersebut (paragraf 20.3, "Efektivitas Relatif Teknik Kualitas"). Tetapi ada juga penelitian swasta di bidang konsultasi yang membuktikan hal itu juga.

Saya punya satu set poin data untuk ini - dari pengalaman yang menjual saya pada tes unit.

Beberapa bulan yang lalu saya adalah lulusan baru yang bekerja pada proyek VB6 besar dan memiliki kesempatan untuk menulis sejumlah besar kode prosedur yang tersimpan. Dari subsistem saya menulis itu terdiri sekitar 1/4 dari seluruh basis kode - sekitar 13.000 LOC dari 50K atau lebih.

Saya menulis satu set unit test untuk prosedur tersimpan tetapi unit pengujian kode UI VB6 tidak benar-benar layak tanpa alat-alat seperti Rational Robot; setidaknya tidak saat itu.

Statistik dari QA pada artikel tersebut adalah bahwa sekitar 40 atau 50 cacat muncul pada seluruh subsistem, yang dua di antaranya berasal dari prosedur tersimpan. Itu satu cacat per 6.500 baris kode vs 1 per 1.000-1.200 atau sekitar seluruh bagian. Ingat juga, bahwa sekitar 2/3 dari kode VB6 adalah kode boilerplate untuk penanganan kesalahan dan logging, identik di semua prosedur.

Tanpa terlalu banyak handwaving, Anda dapat menganggap setidaknya peningkatan tingkat cacat pada tingkat pengujian unit pengujian.