Kolega tidak mau menggunakan tes unit "karena lebih ke kode"

Seorang kolega tidak mau menggunakan tes unit dan sebagai gantinya memilih untuk tes cepat, berikan kepada pengguna, dan jika semuanya baik-baik saja, itu dipublikasikan langsung. Tidak perlu dikatakan bahwa beberapa bug dapat lewat.

Saya menyebutkan bahwa kita harus berpikir tentang menggunakan unit test - tetapi dia menentangnya begitu disadari lebih banyak kode harus ditulis. Ini membuat saya dalam posisi memodifikasi sesuatu dan tidak yakin outputnya sama, terutama karena kodenya spaghetti dan saya mencoba untuk memperbaiki ketika saya mendapat kesempatan.

Jadi apa cara terbaik untuk saya?

Dia tidak mengetahui manfaat pengujian unit dan itulah yang perlu Anda ubah:

• Kesadarannya.

Anda harus membuktikan padanya bahwa itu akan meningkatkan pekerjaannya bukan hanya milik Anda. Itu akan sulit, dia mungkin akan mencoba untuk fokus pada setiap aspek negatif yang bisa dia temukan jika dia takut akan perubahan.

Anda dapat mencoba berdiskusi dengannya tentang semua manfaatnya dan mendengarkan semua pertengkarannya. Tunggu sampai dia selesai berbicara sebelum mulai berbicara sendiri.

Untuk mempersiapkan diri Anda, Anda harus melihat P.SE atau Google untuk semua hal manajemen atau pengembang khawatir tentang pengujian unit dan menyusun jawaban yang akan Anda gunakan selama diskusi Anda dengan kolega Anda.

Hanya mendengarkannya dan memberikan bukti bahwa itu akan meningkatkan pekerjaannya akan banyak membantu Anda. Anda membuktikan bahwa Anda prihatin dengan pendapatnya, dan Anda memberikan semua data yang dia butuhkan untuk menganalisis situasi dan akhirnya berubah pikiran.

Tulis tes unit (jangan katakan padanya)

Tunggu sampai barang rusak, Biarkan dia melakukan tes manual selama dua hari, lalu tarik unit test Anda dan temukan bug dalam tiga detik.

Berlindung...

Mengotomatiskan tugas-tugas manual seharusnya menarik bagi setiap programmer.

Jadi dia tidak "menulis lebih banyak kode" dia melakukan lebih sedikit secara manual.

(Salah satu) poin dari pengujian otomatis adalah pengulangan . Jika Anda melakukan tes cepat dengan tangan, Anda dapat melakukannya menyelesaikannya lebih cepat daripada menulis yang sama dengan tes unit (setidaknya untuk pemula yang menguji unit - siapa pun yang berpengalaman dalam pengujian unit dapat melakukan tes cukup cepat).

Tetapi bagaimana ketika besok, atau minggu depan, perubahan kecil (atau besar ...) dilakukan pada kode? Apakah kolega Anda dengan senang hati mengulangi tes manual yang sama berulang-ulang setelah setiap perubahan, untuk memastikan tidak ada yang rusak? Atau apakah dia lebih suka "kode dan berdoa"?

Semakin banyak kode diubah, semakin banyak unit tes mengembalikan investasi awal Anda . Tidak perlu waktu lama untuk mendapatkan sisi positif, bahkan tanpa tes benar-benar menangkap bug. Tetapi mereka secara teratur juga melakukan itu - pada titik ini, mereka menjadi sangat berharga. Dan begitu seseorang mengalami perasaan aman, dan percaya diri pada kode seseorang yang diberikan oleh unit test yang berhasil, biasanya tidak ada jalan untuk kembali.

Jika dia agak yakin tetapi takut untuk menjelajah ke area baru, tawarkan dia sesi pemrograman pasangan untuk menulis tes unit pertamanya bersama-sama . Pilih kelas yang tidak terlalu sulit untuk diuji tetapi cukup kompleks sehingga layak untuk diuji.

Namun, jika dia tidak yakin, Anda mungkin perlu mengumpulkan fakta-fakta sulit . Fakta seperti itu mungkin saja

• tingkat cacat dalam kode yang ditulis oleh Anda vs miliknya
• menulis satu set unit test terhadap kodenya dan mendokumentasikan bug yang ditemukan.

Kumpulkan beberapa data seperti itu, lalu tunjukkan hasilnya dengan sopan. Jika ini masih belum cukup untuk meyakinkannya, Anda mungkin perlu mendiskusikan masalahnya dan membagikan bukti yang dikumpulkan dengan manajemen. Itu seharusnya menjadi pilihan terakhir Anda, tetapi terkadang tidak ada cara lain.

Tulis cakupan tes dasar untuk bit terburuk dari kodenya, rafactor berdasarkan pada tes-tes tersebut, kemudian buat kasus dengan manajemen bahwa pengujian unit pada build berkelanjutan akan meningkatkan produktivitas. Perubahan menjadi lebih mudah ketika diamanatkan oleh majikan daripada diinjili oleh pengembang tunggal.

Tidak tahu bagaimana mengekspresikan ini dengan benar, tetapi: jika Anda refactoring kodenya "ketika Anda mendapat kesempatan" ... well, dia mungkin berpikir Anda sedikit bodoh karena melibatkan diri Anda dalam "bisnisnya" , jadi kecil kemungkinannya untuk mendengarkan Anda dengan pikiran terbuka. Dalam pengalaman saya, orang-orang menjadi terikat dengan apa yang telah mereka lakukan - bahkan ketika itu tidak terlalu baik.

Untuk berperan sebagai advokat setan: dia benar. Saya biasanya menyebutnya:

Tes otomatis memecahkan masalah banyak kode dengan lebih banyak kode.

Alasan:

• mempelajari tentang korelasi tingkat kesalahan dan metrik OO , hasil utama: "Setelah mengontrol ukuran [kelas] tidak ada metrik yang kami pelajari terkait dengan kesalahan-kecenderungan lagi" . (Ukuran membahas studi kelas. Apakah efek ini meluas ke ukuran basis kode? Mungkin. Di saya pendapat )
• Secara empiris, proyek-proyek besar cenderung berjalan lambat. "5K baris semalam di proyek baru" vs. "10 baris / hari pada proyek besar". Apakah itu menunjukkan "resistensi" untuk berubah meningkat dengan ukuran basis kode?
• Kami selalu menyatakan "tidak ada bahasa terbaik, itu tergantung pada masalahnya." Salah satu persyaratan utama adalah memodelkan entitas masalah dan operasi dengan mudah dalam bahasa pilihan. Bukankah itu menyarankan memilih bahasa di mana mengekspresikan masalah Anda lebih rumit lebih buruk , dan bukankah itu lagi berkorelasi dengan ukuran akhir dari basis kode?

Sekarang, ada beberapa argumen untuk melawan dengan mudah. Biarkan saya alamat yang saya bisa pikirkan:

• ukuran vs kesederhanaan: Tentu saja dimungkinkan untuk membuat kode lebih pendek dan lebih buruk. Namun, itu hanya masalah ketika membandingkan basis kode dengan rasio singkat-kesederhanaan-vs-kesederhanaan, untuk diskusi kita dapat mengasumsikan kita entah bagaimana bisa mengendalikan faktor ini.

• Tes unit menekan Anda untuk mengurangi dependensi, dan saya secara empiris setuju bahwa mengurangi depency dapat mengurangi masalah ukuran kode (dalam arti bahwa dari dua basis kode dengan ukuran yang sama, yang dengan lebih banyak ketergantungan lebih buruk). Namun , sementara mengurangi ketergantungan antara unit kode produksi, ia memperkenalkan sambungan antara tes dan unit itu sendiri.

TL; DR: Saya tidak berpendapat tes unit buruk; Saya bertanya: apakah ada titik impas di mana tes sakit yang berkorelasi dengan jumlah kode?

Saya pikir Anda berada dalam posisi yang sulit. Saya telah berada di tim di mana orang tidak akan menulis tes unit, atau lebih buruk, tes unit tidak dapat dipertahankan yang mengerikan. Tetapi semua orang menyadari fakta bahwa pengujian unit itu baik.

Jadi, mendapatkan unit test unit tim untuk memiliki kualitas yang baik adalah jalan yang sulit. Selalu waspada di mana hal-hal dapat ditingkatkan, menyampaikan gagasan, berbagi pengalaman.

Anda di sisi lain memiliki pengembang yang bahkan belum menyadari manfaatnya. Dan kemudian juga kode kode spageti. Saya kira salah satu alasan paling penting dalam kasus khusus ini adalah fakta bahwa menulis unit test yang bagus memaksa desain yang digabungkan secara longgar. Jadi membuatnya menulis tes semoga dalam jangka panjang juga meningkatkan kode "nyata".

Tapi saya pikir pada akhirnya, itu adalah keputusan tim (saya tidak tahu berapa banyak Anda di tim?). Jika tim dapat mencapai konsensus bahwa harus ada unit test unit yang mencakup dengan baik, maka semua orang harus menyesuaikan, berbagi pengalaman, dan membiarkan tim Anda tumbuh kuat bersama.

Namun jika tim tidak dapat mencapai konsensus bahwa Anda harus menulis tes unit, maka saya sarankan Anda mencari tim pengembangan yang berbeda untuk bekerja bersama;)

Apakah dia bosnya?

Jika demikian ... Anda agak macet kecuali Anda dapat meyakinkannya tentang manfaat yang pada dasarnya sejalan "satu ons pencegahan bernilai satu pon penyembuhan". Bug berhasil. TDD membantu mengurangi hal itu dengan membangun output yang konsisten.

Bukankah dia bosnya?

Apa standar pengkodean tempat Anda bekerja? Kenapa dia diizinkan memuntahkan kode spageti? Sampaikan kasus bisnis kepada bos dengan mengatakan "Kami akan menghabiskan waktu BANYAK lebih sedikit untuk bug jika kami menghabiskan lebih banyak waktu untuk TDD". Meyakinkan seseorang yang dapat menegakkan perubahan dengan kasus bisnis.

Dokumentasikan kasus di mana TDD dapat menghemat waktu & $$ UANG $$.

Bug ini muncul dengan sendirinya. Itu akan ditangkap sebelum ditayangkan. Menghabiskan 2 jam pencegahan akan menghemat 10 jam penyembuhan. Itu terjadi di sini, di sini, dan di sini. Itu 10 jam kerja yang akan menyelamatkan perusahaan 30 jam kerja. Itu uang sebanyak ini.

Ini membuat saya mampu memodifikasi sesuatu

Mengapa?

Mereka menciptakan masalah. Mereka harus menyelesaikannya.

Manajer apa yang memungkinkan ini terjadi? Mengapa kode kereta orang lain sekarang menjadi masalah Anda?

Anda memiliki kolega dan manajer yang membuat ini terjadi. Dan dengan membersihkan kekacauan mereka, Anda adalah peserta yang bersedia dan aktif.

Tidak ada yang akan berubah jika mereka tidak merasakan sakitnya kualitas yang buruk.

Dia benar sekali, unit test adalah "lebih banyak kode".

Namun itu hanya lebih banyak kode yang harus ditulis untuk memastikan bahwa program bekerja sebagaimana mestinya (berulang-ulang). Ini bukan waktu yang terbuang. Ini adalah bagian dari sistem dan juga komponen inti.

Tantang dia di:

1. Apa yang terjadi jika seseorang yang tidak terbiasa dengan kode mengubah sesuatu.
2. Apa yang terjadi jika seseorang yang tidak berpengalaman mengubah sesuatu.
3. Biaya pemeliharaan sistem tidak diukur dalam berapa lama waktu yang dibutuhkan untuk membuat. Ini proposisi jangka panjang. Pikirkan tentang total biaya kepemilikan.
4. Perkiraannya (jika itu diperlukan sebelum pengkodean dimulai) harus mencakup persyaratan untuk menulis tes unit. Para pebisnis tidak membuat persyaratan yang memerlukan pengujian unit secara langsung, tetapi mereka memang memiliki persyaratan kualitas implisit dan mengharuskan perubahan di masa depan tidak dipenuhi dengan bug atau bahwa programmer yang sama mengubah sumbernya.

Berbicara sebagai kode produksi saat ini, ditindaklanjuti dengan unit test daripada TDD, yang tampaknya tidak cocok di tempat saya saat ini (saya sudah melakukan TDD pada beberapa proyek, tetapi melihatnya sebagai alat lain di tas ol, bukan peluru perak) ...

Ini bisa menjadi penjualan yang sulit. Saya masih belum bisa menjual rekan kerja saya di unit testing. Saya tahu bahwa saya cenderung membuat lebih banyak kesalahan dalam kode pengujian unit saya daripada dalam kode produksi saya. Jadi, agak frustasi harus menghabiskan begitu banyak waktu memperbaiki kode uji unit ... Namun, itu asuransi yang bagus ketika kode dimodifikasi. Cara hebat untuk menguji kondisi tepi secara otomatis.

Tunjukkan padanya berapa banyak tes unit membantu dengan membuat tes unit sendiri.

Seperti yang pernah dikatakan Santo Fransiskus, "Berkhotbah Selalu. Bila perlu, gunakan kata-kata."

Jika dia melihat bahwa kode Anda menggunakan tes unit, dan bahwa Anda dapat menyelesaikan bug lebih cepat dengan tes unit, maka itu dapat berubah pikiran. Tapi, mungkin tidak.

Tidak peduli hasilnya, dia tidak melihat Anda mendorong sesuatu yang tidak ingin Anda lakukan. Itulah yang harus Anda ubah, persepsi bahwa Anda tidak memimpin dengan memberi contoh.