Bagaimana cara memotivasi rekan kerja untuk menulis tes unit? [Tutup]

Kami sedang mengerjakan produk besar yang telah diproduksi selama sekitar 5 tahun. Basis kode adalah .. erm .. berfungsi. Tidak terlalu baik tetapi berfungsi. Fitur-fitur baru dilemparkan ke dalam produksi dan diuji dengan QA kecil. Bug diperbaiki, dll. Tapi tidak ada seorang pun, kecuali saya, yang menulis tes unit. Tidak ada yang menggunakan kekuatan "melacak" bug dengan menulis unit test untuk memastikan bug khusus ini (test case) tidak akan pernah terjadi lagi.

Saya sudah bicara dengan manajemen. Saya sudah bicara dengan pengembang. Saya sudah bicara dengan semua orang di seluruh perusahaan. Semua orang berkata: "Ya, kita harus menulis lebih banyak unit-test!" Itu sekitar setahun yang lalu. Sejak itu saya telah memaksa pengenalan ulasan kode pra-komit ( Gerrit ) dan integrasi berkelanjutan ( Jenkins ).

Saya mengadakan beberapa pertemuan tentang tes unit dan saya juga menunjukkan manfaat dari menulis tes unit. Tapi sepertinya tidak ada yang tertarik.

T1: Bagaimana saya memotivasi rekan kerja saya untuk menulis tes unit?

T2: Bagaimana saya tetap termotivasi untuk mengikuti standar kualitas kode pribadi saya? (Terkadang itu benar-benar membuat frustrasi!)

PS: Beberapa fakta yang membuat frustrasi (dicapai dalam 1 tahun):

• Total unit-tes: 1693
• Total "contoh unit-test": sekitar 50
• Dikerjakan oleh saya: 1521

Sunting: Apakah saya terlalu banyak berharap? Ini adalah tempat kerja pertama saya dan saya berusaha melakukan yang terbaik.

Sunting 2: Berdasarkan semua jawaban, saya telah membuat daftar periksa kecil untuk diri saya sendiri. Saya sudah bicara dengan dua pengembang secara pribadi dan kami melakukan pembicaraan yang baik dan jujur.

Salah satu dari mereka memberi tahu saya, seperti yang dikatakan Telastyn , bahwa dia benar-benar tidak nyaman dengan unit-test. Dia mengatakan bahwa dia ingin menjadi "lebih profesional" tetapi dia membutuhkan kickstart. Dia juga mengatakan bahwa pertemuan uji unit kami dengan semua pengembang (sekitar 9-11) itu baik, tetapi terlalu ramai. Ah. Beberapa kritik untuk saya, tetapi saya akan belajar dari itu. (lihat jawaban di bawah dengan pertemuan kata tdd!)

Yang lain mengatakan bahwa dia tidak tertarik untuk menulis unit-tes. Dia berpikir bahwa pekerjaannya cukup baik untuk gajinya. Dia tidak ingin melakukan lebih banyak usaha. Saya cukup terdiam. Khas 9-5 "pekerja".

Minggu depan saya akan berbicara dengan pengembang lain.

Terima kasih atas jawaban Anda yang hebat (sejauh ini!) Dan dukungan Anda. Saya sangat menghargai itu! Saya telah belajar banyak, terima kasih banyak!

Saya perhatikan bahwa berbicara tentang TDD tidak berhasil. Orang suka melihat hasil mentah . Mengatakan bahwa "tes menulis akan mengurangi waktu pengembangan" kemungkinan besar benar, tetapi mungkin tidak cukup untuk meyakinkan siapa pun.

Saya berada di posisi yang sama (well, tidak seburuk milik Anda), dan itu agak teratasi ketika orang-orang mulai bekerja pada kode saya (catatan: kode saya diuji unit, yang lain tidak begitu banyak). Ketika sesuatu berhenti bekerja, tindak lanjut alami setelah penyelidikan lokal adalah untuk bertanya kepada saya apa yang bisa menjadi alasannya . Kemudian kami duduk, kami menjalankan unit test dan melihat apa yang terjadi. Jika tes lulus, sebagian besar masalah waktu berada pada kode baru yang belum diuji. Jika tidak, tes biasanya dapat menemukan masalah (atau setidaknya mengarahkan kita ke arah yang benar). Kami memperbaiki bug, tes kembali, semua orang senang.

Singkat cerita, beberapa situasi seperti ini terjadi dan 2 lebih banyak pengembang menjadi penggemar TDD / pengujian (masih ada beberapa lagi, tetapi terlihat menjanjikan).

Adapun saran, Anda bisa mencobanya dengan TDD kata; tugas sederhana untuk diimplementasikan menggunakan pendekatan tes pertama sebagai lawan dari tes tidak ada . Bergantung pada seberapa kompleks tugas itu, pendekatan non-tes biasanya harus lebih lambat, terutama dengan perubahan tambahan yang disyaratkan:

• Kalkulator string Roy
• Bank OCR

Sunting : Komentar OP membuat saya menyadari bahwa ada argumen yang lebih kuat yang dia miliki - regresi alias bug yang kembali . Situasi semacam itu adalah contoh sempurna yang menunjukkan bagaimana unit test dapat bermanfaat. Orang-orang seperti angka - seperti yang saya katakan, mengatakan "unit testing baik" mungkin tidak meyakinkan, tetapi mengatur data seperti di bawah ini mungkin pasti:

• waktu yang dihabiskan untuk mengimplementasikan fitur (tidak ada tes yang ditulis; Saya menganggap ini sering terjadi sehingga seharusnya relatif mudah untuk menemukan contoh seperti itu)
• perkiraan waktu untuk mengimplementasikan fitur dengan TDD (atau bahkan tes setelah pendekatan; tidak masalah - yang penting adalah adanya tes unit)
• waktu yang dihabiskan untuk menyelesaikan bug pada kode yang belum diuji vs diuji

Satu hal yang perlu Anda ingatkan (migth ini sudah jelas tetapi patut dicatat): bias hasil - pastikan Anda tidak memilih contoh di mana satu-satunya cara menemukan bug dengan tes adalah dengan menulis tes untuk bug itu. Biasanya, tidak ada yang tahu bug akan muncul dimuka, tetapi tergoda untuk mengatakan "man bug ini akan sepele jika kita menguji X" - mudah untuk menemukan taktik kemenangan untuk perang setelah itu berakhir.

Hasil dari contoh-contoh itu seharusnya berupa pertanyaan sederhana - jika Anda dapat menghabiskan waktu x-jam mengembangkan fitur Y, mengapa bersikeras melakukannya dalam 2x ?

Pertama, Anda harus tahu mengapa mereka tidak menulis tes.

Jadwal dev yang ketat sering menjadi alasannya, tetapi Anda mengatakan Anda tidak memilikinya.

Alasan berikutnya adalah bahwa dengan basis kode yang belum teruji yang besar, menulis tes mungkin kelihatannya luar biasa - pekerjaan yang tidak pernah berakhir (seperti mencuci pakaian dan hal-hal yang menyenangkan). Jadi sifat manusia adalah berpikir bahwa itu terlalu banyak untuk dihadapi, jadi saya akan melewatkannya.

Alasan lain bisa jadi bahwa meskipun mereka berpikir tes adalah ide yang baik, mereka tidak yakin tentang bagaimana memulai menulis mereka terutama jika mereka tidak pernah bekerja di mana pun yang menulisnya.

Kemungkinan lain yang kuat adalah karena mereka benar-benar tidak melihat adanya nilai untuk lebih banyak pekerjaan meskipun mereka memberikan ide yang manis.

Jadi bagaimana Anda menangani berbagai alasan?

Alasannya sederhana, tunjukkan pada mereka contoh bagaimana menghemat waktu pengembangan.

Alasan dua - tunjukkan pada mereka berapa banyak tes yang Anda tulis dalam setahun dan berapa persen basis kode yang dicakupnya. Lakukan perhitungan matematika untuk menunjukkan berapa banyak lagi tes yang bisa mereka lakukan saat ini tahun depan jika mereka melakukan ini. Begitu mereka melihat bahwa sedikit kemajuan setiap hari benar-benar bertambah, seluruh gagasan itu tidak begitu luar biasa. Jika Anda dapat menarik data keluar dari sistem, perlihatkan kepada mereka berapa banyak bug yang merupakan bug berulang di bagian kode yang belum diuji dan berapa banyak bug berulang yang muncul dalam kode dengan unit test.

Alasan 3 adalah pelatihan, bukan hanya menunjukkan. Buat mereka menulis tes di kelas pelatihan.

Alasan 4, inilah inti masalahnya. Pertama, pilih titik sakit, salah satu bug yang telah kembali beberapa kali. Ketika itu masuk, inilah saatnya untuk menyarankan kepada manajemen bahwa jika mereka memiliki unit test pada item ini, itu tidak akan terus datang kembali seperti satu sen yang buruk.

Cara lain untuk mengatasi alasan 4 adalah membuat manajemen menjadikannya bagian dari proses dan kode tidak lulus tinjauan kode kecuali jika tes juga lulus tinjauan kode. Terbaik untuk mendekati mereka dengan membuat kebijakan ini tepat setelah salah satu dari titik-titik rasa sakit atau lebih baik setelah Anda memiliki beberapa dalam hitungan hari.

Kita semua suka berpikir bahwa sebagai pengembang kita mengelola sendiri (LOL), tetapi orang yang ambisius akan peduli tentang apa yang ditekankan oleh manajemen kepada mereka yang harus mereka pedulikan dan para profesional yang benar-benar mengelola sendiri sudah menulis ujian. Jika mereka tidak peduli tentang menjadi profesional dan melakukan praktik terbaik karena mereka meningkatkan produk atau peduli bagaimana membuat manajer terkesan dipromosikan (atau tidak dipecat), maka Anda dapat mempertimbangkan apakah ini tempat yang tepat untuk Anda. Jika Anda tidak dapat membuat manajemen peduli dengan praktik terbaik, maka Anda akan terus berjuang keras, Anda mungkin menilai apakah ini budaya perusahaan yang tepat untuk Anda. Meskipun setiap tempat kerja memiliki masalah (dan melarikan diri tidak selalu merupakan jawaban), tempat ini tampaknya tidak sesuai dengan tingkat profesionalisme Anda.

Saya akan mulai dengan menunjukkan manfaat TDD. Cobalah untuk menunjukkan manfaat pengujian unit.

Sebagai manusia normal, pengembang termotivasi oleh manfaat. Mereka tidak ingin melakukan hal-hal yang hanya menciptakan lebih banyak pekerjaan. Pengujian unit berarti lebih sedikit pekerjaan . Itu berarti pacaran lebih banyak dengan teman. Itu berarti bersenang-senang karena Anda tidak perlu menghabiskan setiap malam coding sampai 11 malam. Itu berarti pergi berlibur lebih banyak dengan ketenangan pikiran.

Salah satu manfaat terbesar dari TDD adalah bahwa Anda dapat refactor program Anda untuk desain yang lebih baik atau hanya mengubah nama sesuatu ... dan selama desain yang tidak merusak tes, Anda dapat memiliki keyakinan 100% bahwa perubahan Anda tidak merusak apa pun.

Kasus hebat lainnya untuk TDD adalah membuat unit test untuk kode lawas . Ini akan mewakili salah satu cara terbaik untuk mulai mengembalikan kejahatan. Dalam jangka panjang, ini akan berfungsi untuk meningkatkan pengetahuan Anda tentang basis kode, memahami kekuatan dan kekurangannya, mengenali logika bisnis kode-keras dalam kode dan memberi Anda awal yang baik untuk meningkatkan kualitas bergerak maju!

Referensi yang baik untuk dibaca lebih lanjut:

• Mengapa Anda Harus Menulis Tes Unit
• Visibilitas Motivasi, dan Pengujian Unit
• Seni pengujian unit, menurut Roy Osherove

http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first

Saya pikir saya menandai tautan itu dari artikel Jeff Atwood beberapa waktu lalu [edit: ya, ini dia] . Tua tapi relevan. Karena manfaat ini dan lainnya yang pasti akan diuraikan dalam jawaban lain, programmer Anda harus dapat memotivasi diri mereka sendiri ! Ini akan memungkinkan mereka untuk bekerja lebih efisien dan dengan demikian membuat pekerjaan mereka sedikit lebih mudah. Siapa yang tidak menginginkan itu?

Sehubungan dengan pertanyaan kedua Anda: rasa kepemilikan dan kebanggaan Anda terhadap standar kualitas kode Anda akan membuat Anda tetap menggunakannya . Pikirkan tentang apa yang ingin Anda capai dengan memiliki standar seperti itu dan siapa yang diuntungkan darinya. Standar kode pribadi saya bisa membuat frustrasi juga, tetapi saya selalu merasa seperti saya melakukan kebaikan dunia / perusahaan / tim dengan menerapkannya. Jadi saya tidak berpikir Anda mencoba melakukan terlalu banyak - hasilnya akan bervariasi dari satu tempat ke tempat lain tetapi setidaknya Anda berusaha.

Ini seperti contoh besar tentang kepemimpinan .

Ada dua aspek bawaan dari sifat manusia yang Anda lawan:

• Orang kreatif tidak suka proses.
• Kebanyakan orang tidak suka penilaian negatif eksternal pada kualitas mereka.

Sangat sulit untuk melawan ini dengan kuliah, pernyataan manajemen, atau bahkan logika. Anda harus menang memanfaatkan aspek alternatif dari sifat manusia.

• Orang-orang meniru perilaku karyawan terbaik

Jika karyawan terbaik menggunakan TDD dan berfungsi, prosesnya akan berkembang. Jika tidak, itu tidak akan terjadi. Jika Anda perlu meyakinkan siapa pun, itu adalah 1 atau 2 karyawan teratas.

Tanya mereka.

Anda mengatakan bahwa orang telah diberitahu, dan setuju bahwa mereka harus menulis lebih banyak tes. Kenapa tidak?

Mungkin tidak (sering kali tidak) masalah motivasi sederhana. Mereka mungkin melupakan mereka. Mereka mungkin merasa di bawah tekanan waktu. Mereka mungkin tidak tahu bagaimana menulis tes yang bagus. Mereka mungkin berpikir Anda sangat baik sehingga mereka tidak perlu melakukannya. Mengetahui akar penyebabnya akan membantu Anda memecahkan masalah dengan lebih baik.

Anda akan berpikir unit test akan menjadi penjualan sendiri. Saya tidak tahu bagaimana perusahaan Anda bekerja, tetapi ketika ada masalah selama peluncuran produksi kami mengerjakannya sampai diperbaiki. Tidak masalah jika itu terjadi pada jam 2 pagi pada hari Minggu pagi. Ini sangat jarang bagi kita, tetapi ketika itu terjadi, itu menyebalkan.

Saya akan mulai dengan bertanya kepada mereka berapa kali mereka harus bangun di tengah malam untuk memperbaiki beberapa masalah besar yang dapat dengan mudah ditemukan pengujian otomatis. Itu tidak berarti pengujian otomatis akan memperbaiki semuanya, tetapi seharusnya membantu mengurangi itu.

Penjual besar kedua adalah siklus QA. Sebelum dimulainya TDD di perusahaan saya, kami akan mendorong rilis baru ke QA untuk diuji setiap minggu. Mereka akan membuat setumpuk bug dari rilis itu, kami memperbaiki bug itu dan mendorong rilis lain. Ulangi sampai selesai. Proyek pertama yang kami lakukan TDD tidak memerlukan push to QA sampai beberapa minggu kemudian. Dan jumlah bug yang ditemukan sangat, sangat kecil. 10% dibandingkan dengan proyek serupa. Apakah Anda tetap harus mengumpulkan statistik tersebut untuk tim Anda?

Titik penjualan besar lainnya adalah bagaimana kode terlihat setelah TDD dirangkul, lebih mudah dibaca, karena kami ingin membuatnya lebih mudah untuk diuji. Tunjukkan perbandingan antara kode yang ditulis untuk unit test dan kode yang tidak tertulis.

Akhirnya, tunjukkan pada mereka bagaimana mereka akan dapat memperbaiki kode dengan percaya diri.

Ingatlah semua itu ketika Anda tidak ingin menulis tes. :)

Saya ingin memperluas jawaban HLGEM , terutama bagian ini:

Alasan berikutnya adalah bahwa dengan basis kode yang belum teruji yang besar, menulis tes mungkin kelihatannya luar biasa - pekerjaan yang tidak pernah berakhir (seperti mencuci pakaian dan hal-hal yang menyenangkan). Jadi sifat manusia adalah berpikir bahwa itu terlalu banyak untuk dihadapi, jadi saya akan melewatkannya.

Saya telah menemukan bahwa kode yang saya tulis dengan maksud tes menulis adalah kode yang jauh lebih baik daripada kode yang saya tulis tanpa maksud tes menulis; bertanya pada diri sendiri Bagaimana saya akan menguji fungsi ini? memaksa desain yang lebih baik untuk setiap fungsi. (Kurang mengandalkan data global atau semi-global; IO terpisah dari perhitungan; fungsi hanya melakukan satu hal; penanganan kesalahan yang konsisten; dan sebagainya.)

Mencoba menguji kode lama yang tidak ditulis dengan pengujian mungkin membuat frustrasi.

Saya telah menggunakan beberapa teknik:

a) mengatur bangunan otomatis. Ketika seseorang merusak sesuatu yang Anda uji, tunjukkan pada mereka bagaimana tes mendeteksi dan seberapa buruk bug itu.

b) Lakukan proyek kompleks dengan tes (Anda mengemudi). Ini akan menunjukkan betapa sedikitnya bug yang ada di proyek itu. Saya punya satu proyek interaksi server yang kompleks yang mulai bekerja dengan sempurna. Tidak pernah gagal QA dan semua tes integrasi berjalan 100% dengan lancar. Sistem itu dikenal sebagai sangat stabil dan manajemen secara keseluruhan senang dengannya. Apa yang Anda lakukan dalam situasi ini adalah bagaimana pengujian unit diaktifkan.

c) Tarik satu orang sekaligus. Orang yang mendengarkan Anda. Ambil bug dan tunjukkan bagaimana tes memperlihatkan masalah yang dalam dan sulit. Ini membantu. Tidak pernah hal yang mudah. Tapi begitu Anda mendapatkan penggemar, dia hanya akan membantu. Ini efek domino.

Panggang pengujian unit dalam proses. Jika bug muncul dalam produksi yang terlalu jelas untuk ditangkap dalam unit test maka orang ini yang disalahkan. Tugaskan orang untuk menulis setiap tes yang mereka buat. Pilih kasus secara acak dan saksikan eksekusi beberapa kasus setiap minggu. Dengan melakukan tes unit, orang akan bertanya tentang persyaratan dan akhirnya mengikat persyaratan untuk pengembangan dan mudah-mudahan mengembangkan perangkat lunak yang diperlukan dan berfungsi :)