Apa efek dari membuat unit test selama pengembangan pada waktu untuk berkembang serta waktu yang dihabiskan dalam kegiatan pemeliharaan?

Saya seorang konsultan dan saya akan memperkenalkan unit test kepada semua pengembang di situs klien saya. Tujuan saya adalah untuk memastikan bahwa semua aplikasi baru harus memiliki unit test untuk semua kelas yang dibuat.

Klien memiliki masalah dengan biaya perawatan yang tinggi dari memperbaiki bug di aplikasi mereka yang ada. Aplikasi mereka memiliki masa hidup antara 5-15 tahun di mana mereka terus menambahkan fitur baru. Saya cukup yakin bahwa mereka akan mendapat manfaat besar dari mulai dengan unit test.

Saya tertarik dengan efek pengujian unit pada waktu dan biaya pengembangan:

• Berapa banyak waktu yang akan ditambahkan pada tes unit sebagai bagian dari proses pengembangan?
• Berapa banyak waktu yang akan dihemat dalam kegiatan perawatan (pengujian dan debugging) dengan memiliki unit test yang baik?

Apakah ada statistik yang tersedia untuk berapa lama waktu yang dibutuhkan untuk mengembangkan aplikasi saat membuat unit test selama pengembangan dibandingkan dengan hanya coding?

Ada beberapa penelitian yang sangat menarik tentang ini. Baca whitepaper berikut:

Menyadari peningkatan kualitas melalui pengembangan yang digerakkan oleh tes: hasil dan pengalaman dari empat tim industri

Buku putih dan penelitian lain dari salah satu penulisnya, Nachi Nagappan , dibahas di sini: http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx

Studi dan hasilnya diterbitkan dalam makalah yang berjudul Menyadari peningkatan kualitas melalui pengembangan yang digerakkan oleh tes: hasil dan pengalaman dari empat tim industri, oleh Nagappan dan rekan penelitian E. Michael Maximilien dari IBM Almaden Research Center; Thirumalesh Bhat, pemimpin pengembangan perangkat lunak utama di Microsoft; dan Laurie Williams dari North State State University. Apa yang ditemukan tim peneliti adalah bahwa tim TDD menghasilkan kode yang 60 hingga 90 persen lebih baik dalam hal kepadatan cacat daripada tim non-TDD. Mereka juga menemukan bahwa tim TDD membutuhkan waktu lebih lama untuk menyelesaikan proyek mereka — 15 hingga 35 persen lebih lama.

"Selama siklus pengembangan 12 bulan, 35 persen adalah empat bulan lagi, yang sangat besar," kata Nagappan. “Namun, pengorbanannya adalah Anda mengurangi biaya perawatan pasca-rilis secara signifikan, karena kualitas kode jauh lebih baik. Sekali lagi, ini adalah keputusan yang harus diambil oleh manajer — di mana mereka harus menerima pukulan? Tapi sekarang, mereka sebenarnya memiliki data kuantitatif untuk membuat keputusan itu. "

Selain itu, Jason Gorman telah mengusulkan eksperimen semacam itu untuk konferensi Pengerjaan Perangkat Lunak tahun ini. Dia telah mencoba percobaan membuat aplikasi yang sama menggunakan TDD dan pendekatan non-TDD dan dia baru - baru ini membuat blog tentang hasil-hasilnya :

Lebih dari 3 iterasi, waktu rata-rata yang diambil untuk menyelesaikan kata tanpa TDD adalah 28m 40-an. Waktu rata-rata dengan TDD adalah 25m 27s. Tanpa TDD, rata-rata saya membuat 5,7 pass (mengirim ke pengujian penerimaan). Dengan TDD, rata-rata saya membuat 1,3 lintasan (dalam dua upaya, mereka lulus pertama kali, dalam satu itu butuh 2 lintasan)

Sekarang, ini adalah eksperimen bayi, tentu saja. Dan tidak persis kondisi laboratorium. Tapi saya perhatikan beberapa hal menarik, sama saja.

Akan menarik untuk melihat hasil lengkap dari percobaan ini ketika lebih banyak orang melakukannya.

Apakah ada statistik yang tersedia yang menunjukkan berapa jam pemeliharaan berkurang ketika melakukan tes unit (baik)?

Dari whitepaper di atas:

Hasil studi kasus menunjukkan bahwa kepadatan cacat pra-rilis dari empat produk menurun antara 40% dan 90% dibandingkan dengan proyek serupa yang tidak menggunakan praktik TDD.