Saya ingin memperkenalkan konsep unit test (dan pengujian secara umum) kepada rekan kerja saya; saat ini tidak ada tes sama sekali dan hal-hal diuji dengan benar-benar melakukan tugas-tugas melalui UI untuk melihat hasil yang diinginkan. Seperti yang Anda bayangkan, kode ini sangat erat digabungkan dengan implementasi yang tepat - bahkan menghasilkan kode yang harus di kelas dan digunakan kembali di seluruh sistem yang disalin dan ditempelkan di seluruh metode.

Karena perubahan persyaratan, saya telah diminta untuk memodifikasi modul yang saya tulis sebelumnya dan itu cukup longgar (tidak sebanyak yang saya inginkan, tetapi yang terbaik yang bisa saya dapatkan tanpa harus memperkenalkan banyak konsep lain). Saya telah memutuskan untuk memasukkan serangkaian unit test dengan kode revisi saya untuk "membuktikan" bahwa itu berfungsi seperti yang diharapkan dan menunjukkan bagaimana pengujian bekerja; Saya tidak mengikuti TDD sejati karena beberapa kode sudah ditulis tetapi saya berharap untuk mengikuti beberapa konsep TDD untuk kode baru yang harus saya buat.

Sekarang, mau tidak mau saya yakin saya akan ditanya mengapa saya perlu lebih dari satu atau dua hari untuk menulis kode, karena bagian dari apa yang saya akan berinteraksi dengan sudah ada dalam sistem (meskipun tanpa tes dan sangat erat digabungkan), dan ketika saya memeriksa kode saya akan ditanya apa proyek "Tes" ini. Saya dapat menjelaskan dasar-dasar pengujian, tetapi saya tidak bisa menjelaskan manfaat sebenarnya dengan cara yang dimengerti orang lain (karena mereka pikir pengujian mengharuskan Anda untuk menjalankan aplikasi sendiri, karena sering kali UI sebenarnya penting dalam menentukan apakah fitur "berfungsi" " atau tidak). Mereka tidak memahami gagasan lepas kopling (jelas terbukti oleh fakta bahwa tidak ada yang longgar digabungkan; bahkan tidak ada antarmuka di luar kode yang saya tulis), jadi mencoba menggunakannya sebagai keuntungan mungkin akan memberi saya "Hah?" jenis tampilan, dan sekali lagi saya tidak bisa menjadi longgar seperti yang saya inginkan tanpa harus mengerjakan ulang beberapa modul yang ada dan mungkin memperkenalkan beberapa jenis wadah IoC, yang akan dilihat sebagai membuang-buang waktu dan bukan "pemrograman".

Adakah yang punya saran tentang bagaimana saya dapat menunjuk ke kode ini dan mengatakan "Kita harus mulai membuat unit test" tanpa keluar sebagai salah satu merendahkan (mis. "Tes menulis memaksa Anda untuk menulis kode yang baik." kecuali milik saya buruk ) atau tanpa membuatnya tampak seperti buang-buang waktu yang tidak menambah nilai nyata?

Saya ingin memperkenalkan konsep unit test (dan pengujian secara umum) kepada rekan kerja saya

Saya pikir mungkin lebih baik untuk memulai dari sisi praktis, bukan konseptual. Tentu saja, jika Anda menemukan selama diskusi santai bahwa rekan kerja dan / atau manajemen Anda tertarik untuk mendengar tentang pengujian unit, semuanya lebih baik - maka Anda dapat mencari beberapa pengalaman / bukti nyata dari web, mengumpulkan pelatihan singkat, dll. Namun, dari apa yang Anda gambarkan, sepertinya rekan kerja Anda tidak terlalu terbuka dengan ide baru yang aneh ini.

Dalam situasi seperti itu, saya hanya akan mulai menulis tes unit kecil saya tanpa mencoba menjelaskan terlalu banyak kepada siapa pun terlebih dahulu. Tambahkan beberapa dari mereka setiap kali saya mengubah kode, tanpa mencoba untuk sepenuhnya menutupi semua kode (yang akan memakan banyak waktu). Idealnya, jika saya berhasil mencapai keseimbangan yang baik, pada saat mereka menyadari saya sedang menulis unit test, saya mungkin sudah memiliki test suite yang substansial, dan beberapa hasil konkret untuk ditampilkan (seperti "dengan test case ini saya berhasil menangkap bug diperkenalkan oleh perubahan minggu lalu, yang jika tidak akan lolos ke QA / produksi "). Itu akan membuktikan nilai tes untuk pengembang serius.

Setelah itu, saya dalam posisi yang baik untuk mulai menjelaskan manfaat jangka panjang dari pengujian unit, seperti

• itu membuktikan bahwa kode itu berfungsi - kapan saja, di mana saja, secara instan dan otomatis, yang pada gilirannya
• memberikan kepercayaan pada refactor, menghasilkan desain yang lebih baik dan perawatan yang lebih baik,
• dan jika ada yang rusak, unit test memberi Anda (hampir) umpan balik instan, yang bertentangan dengan latensi beberapa hari atau minggu jika bug ditangkap oleh departemen QA yang terpisah. Yang biasanya memungkinkan Anda untuk memperbaiki bug dalam hitungan detik, bukannya debugging selama berjam-jam / hari, dalam kode yang telah lama hilang dari memori jangka pendek Anda.

Lihat juga utas terkait ini: Pengujian unit otomatis, pengujian integrasi, atau pengujian penerimaan .

Dan yang sebelumnya dari SO: Apa itu pengujian unit?

Faktor ulang tanpa Ketakutan

Sebagai sudut pandang yang sedikit berbeda, TDD memungkinkan Anda untuk "faktor ulang tanpa rasa takut", dan ini adalah manfaat utama Anda dapat menjual tim Anda. Ini menghentikan pengembang untuk mengatakan kepada diri mereka sendiri:

• "Aku tidak ingin menyentuh kode ini karena aku takut aku akan memecahkannya"
• "Saya tidak ingin menulis fungsionalitas baru untuk membuka kode ini karena saya tidak tahu cara kerjanya"
• "Diam-diam, aku takut kode itu"

Saya bisa memainkan lebih banyak lagi, tetapi ini adalah tanah yang tertutup dengan baik seperti Paman Bob di TDD dan Martin Fowler di TDD .

Ketergantungan

Oh, aku akan menambahkan satu hal lagi. Ini akan menunjukkan kepada mereka bagaimana TDD memaksa desain yang baik yang memungkinkan Anda menangani dependensi secara bersih.

Bob: "Oh c% ^ p! Atasan hanya memaksa kita semua untuk menggunakan MS SQL Server 2008" Jane: "Tidak apa-apa, kerusakan dalam diminimalkan karena kita DI sumber data dan kelas DAO kita, saya sangat senang TDD mendorong kita menyusuri jalan itu. "

Saat bekerja pada kode sumber yang tidak memiliki tes otomatis, Kami harus bekerja dengan sangat hati-hati dan membutuhkan lebih banyak ulasan untuk tetap percaya diri bahwa perubahan yang kami buat tidak merusak fungsi apa pun yang ada.

Ketika kami memiliki kasus pengujian otomatis yang baik, konsekuensinya akan lebih cepat, percaya diri dan pengembangan tanpa rasa takut (bisa berupa perbaikan bug, peningkatan atau anjak piutang).

Lakukan perhitungan

• t _mt = waktu yang diperlukan untuk menguji secara manual segala hal yang Anda bayangkan mungkin memengaruhi
• t _wt = waktu yang dibutuhkan untuk menulis tes

• k = berapa kali Anda mungkin harus menguji semuanya sebelum merilis kode baru

  Jika (t _wt <t _mt ) atau (t _wt <(k * t _mt )) maka itu adalah no-brainer: menulis tes akan mempercepat pengembangan.

kalau tidak lihat rasio (t _wt / (k * t _mt )). Jika jumlahnya sangat banyak maka tunggu kesempatan lain; jika tidak dibenarkan dengan manfaat pengujian regresi.

Catatan: Saya menyarankan saat ini untuk hanya menguji fitur, bukan unit - jauh lebih mudah untuk dibenarkan dan dipahami, dan bisa dibilang lebih sedikit bekerja dengan nilai yang lebih tinggi daripada hanya tes unit saat refactoring.

Catatan 2: waktu yang diperlukan untuk menjalankan tes tidak masalah , karena itu otomatis. Anda dapat melakukan hal lain yang produktif saat tes berjalan, kecuali jika tes berjalan terlalu lama sehingga mereka akan membuat Anda melewatkan tenggat waktu. Yang jarang.

Satu saran jika Anda adalah toko Microsoft: temukan beberapa dokumentasi tentang MSDN yang merekomendasikan pengujian unit atau pelonggaran longgar sebagai praktik terbaik (saya yakin ada beberapa contoh ini ) dan tunjukkan jika ada konflik.

Ini mungkin terdengar seperti cara kasar dalam melakukan sesuatu, tetapi saya telah menemukan bahwa menggunakan istilah 'praktik terbaik' akan membawa Anda jauh terutama dengan manajemen.

Seperti yang selalu saya rekomendasikan, jika Anda mengetahui praktik hebat, cara terbaik untuk memperkenalkannya dengan lembut ke lingkungan Anda tentu saja untuk mulai melakukannya sendiri dan kemudian di suatu tempat di sepanjang jalan, beberapa rekan kerja Anda akan melihat manfaat dan ambil itu.

Kata kunci di sini adalah evolusi, bukan revolusi.