Bagaimana cara membuat lingkungan di mana tes perbaikan dilihat sebagai prioritas?

Saya seorang insinyur perangkat lunak di perusahaan menengah. Kami memiliki platform pengujian yang cukup kuat yang berjalan di TeamCity. Itu melakukan tes unit pada setiap checkin, dan menjalankan tes unit / BVT harian.

Masalahnya adalah - kami memiliki banyak unit test yang rusak.

Cukup sering, saya mengemukakan kegunaan dari unit test jika mereka terus-menerus rusak dan tidak dirawat. Tidak dapat melihat apakah perubahan telah menyebabkan regresi menghapus sebagian besar nilai platform pengujian unit.

Saya ingin menanam benih yang akan menciptakan budaya kebiasaan yang baik - memperbaiki tes ketika mereka rusak, melihatnya bernilai, memprioritaskan penetapan tes bersama dengan pekerjaan lain.

Saya sudah mencoba suap (barang yang dipanggang!), Sekadar bertanya, dan berbicara dengan pimpinan tim. Semua orang mengatakan itu ide yang bagus, tetapi saya melihat menjadi satu-satunya yang melakukan sesuatu tentang itu.

Apa cara terbaik untuk memulai mendorong orang lain untuk memperbaiki tes mereka, dan memprioritaskan perbaikan tes dalam sprint mereka?

Jika ada cara yang kurang subyektif untuk menanyakan hal ini, saya akan dengan senang hati menerima tip.

— Codeman
sumber

pistol nerf otomatis ditujukan pada orang yang melanggar bangunan ...

— ratchet freak

Kami benar-benar memiliki pistol nerf otomatis ... tetapi build tidak rusak, hanya tes unit :)

— Codeman

Memecah tes unit harus menyiratkan melanggar membangun. ;)

— Jeroen Vannevel

@ Ӎσᶎ: Buy-in penting, tetapi Anda tidak bisa mendapatkan buy-in untuk menyelesaikan masalah sampai orang-orang benar-benar menyadari masalah tersebut. Dalam hal ini kebutuhan buy-in awalnya hanya berasal dari pimpinan tim dan manajer. Dukungan pengembang dapat datang kemudian dan umumnya akan, secara alami, ketika sistem pembangunan telah diatur untuk membuat pengembang individu membayar kesalahan mereka sendiri.

— Aaronaught

Jika donat gagal, Anda bersulang. :-)

— Ross Patterson

Jawaban:

Buat itu jadi tidak mungkin untuk benar-benar melepaskan apa pun tanpa memperbaiki tes.

Gagal membangun jika ada tes yang gagal.
Gagal membangun jika ada tes yang diabaikan.
Gagal membangun jika cakupan pengujian berada di bawah level tertentu (jadi orang tidak bisa hanya menghapus tes untuk mengatasinya).
Gunakan server CI untuk melakukan rilis build Anda, dan hanya mengizinkan build dari drop build server untuk dipromosikan menjadi UAT / staging / produksi / apa pun.

Faktanya adalah, jika bangunan Anda rusak selama lebih dari 15 menit sekaligus (dan itu termasuk tes gagal), maka Anda tidak melakukan integrasi terus menerus .

"Opsi nuklir" adalah meminta server kontrol sumber Anda menolak komit / checkin dari pengguna mana pun selain dari orang yang merusak build. Jelas seorang admin harus dapat mengesampingkan ini sementara jika orang tersebut pergi berlibur - tetapi, jika semua orang tahu bahwa seluruh tim kacau sampai mereka memperbaiki tes mereka, maka mereka akan menyelesaikannya dengan cepat.

Kebijakan yang baik (yang bahkan lebih baik ketika itu otomatis) adalah mengembalikan sumber ke komit stabil terakhir yang diketahui setelah 15 menit pembangunan gagal. Dengan kata lain, jika Anda tidak bisa memperbaikinya, atau tidak tahu apa yang menyebabkan build atau tes rusak, maka kembalikan dan bekerja secara lokal sampai diselesaikan - tidak pernah membuat pengembang lain memelintir ibu jari mereka saat Anda mengerjakan sesuatu masalah yang tidak mereka pedulikan.

PS Jika Anda sudah memiliki banyak tes gagal, Anda dapat menggunakan "trailing threshold" di CI. Atur agar build hanya gagal jika ada lebih banyak kegagalan pengujian daripada yang terakhir. Ini, bersama dengan aturan cakupan, akan memaksa pengembang untuk akhirnya memperbaiki situasi pengujian jika mereka ingin tetap bekerja.

PPS Saya menyadari ini mungkin tampak kejam bagi sebagian orang, tetapi itu semua tergantung budaya Anda. Jika Anda sampai pada titik di mana orang tidak membiarkan build rusak atau tes gagal (tim saya hampir tidak pernah melakukannya, walaupun saya kadang-kadang harus mengingatkan mereka), maka Anda tidak perlu melanjutkan dengan seperangkat aturan ketat. Meskipun IMO Anda harus selalu gagal membangun pada unit test yang rusak. Tes integrasi / browser terkadang gagal.

— Aaronaught
sumber

Sementara semua petunjuk teknis Anda berguna, saya pikir bagian paling berharga dari jawaban Anda adalah bahwa “Ini semua budaya Anda” karena lebih dari masalah disiplin, itu adalah masalah kegunaan yang dirasakan dari tes. Saya lebih suka meletakkannya di depan daripada di PPS

— user40989

@ user40989: Saya mendengarmu. Budaya adalah sesuatu yang harus Anda kembangkan. Jika Anda ingin orang memahami betapa pentingnya tes, Anda terkadang harus membuatnya sehingga orang tidak dapat mengabaikannya. Setelah orang terbiasa dengan cakupan kode dan tes hijau tingkat tinggi, mereka tidak ingin kembali, dan kemudian pengembang Anda sendiri akan menerapkannya untuk rekrut baru. Semoga saja. Pimpinan tim anal-retentive dan / atau build master dan / atau manajer membantu. :)

— Aaronaught

FWIW: Seluruh proses rilis kami sekarang terotomatisasi dan orang-orang tidak akan berpikir untuk melakukan tes yang rusak. Pimpinan tim melakukan penggabungan ke master, kemudian memulai rilis pengembangan, dan mengirimkan permintaan promosi ke sysadmin yang benar-benar menekan tombol untuk digunakan dari artefak build dan menjalankan browser otomatis dan uji API. Tidak ada yang mengeluh tentang proses ini, pernah, karena menghemat waktu - kami dulu menghabiskan 2 minggu meributkan rilis, sekarang pada dasarnya adalah gelombang tangan. Inilah yang saya maksud dengan mengolah budaya - semua orang tahu bahwa tambahan 2 menit untuk memperbaiki tes akan menghemat 2 jam kemudian.

— Aaronaught

Tes unit yang gagal bukan masalah. Mereka adalah gejala .

Masalah sebenarnya adalah dalam budaya. Anda harus melangkah dengan lembut: ini naga . Anda tidak dapat mengubah budaya sendiri, dan menjadi roda yang melengking pada akhirnya akan membuat Anda menjadi orang buangan. Secara harfiah.

Saya sarankan jika Anda mencoba menemukan orang senior untuk memperjuangkan penyebabnya dan memimpin. Jika gagal, coba angkat dalam rapat pengembang umum, tanpa menunjukkan jari atau memanggil nama. Alternatif lain adalah mengambil tanggung jawab sendiri untuk melakukan pekerjaan yang tepat: perbaiki beberapa tes lagi setiap kali Anda melakukan check-in. Buatlah bagan di dinding yang menunjukkan berapa banyak tes yang gagal seiring waktu. Orang lain akan melihatnya: mungkin mereka akan ikut serta.

Tidak ada jawaban yang mudah.

— andy256
sumber

Menjadi roda melengking membuat saya memimpin tim. Mungkin ada yang salah dengan mencicitmu? Namun, dalam semua keseriusan, itu berbicara dengan masalah budaya yang sangat berbeda , tidak dengan tim pengembang tetapi dengan manajemen perusahaan. Jika respons manajemen terhadap api yang menyala adalah mengenakan kacamata hitam, maka pergilah dari sana. Tetapi jika Anda benar-benar toko dev , sebagai lawan dari departemen IT perusahaan yang mengeluarkan perangkat lunak dari pusat biaya, kemungkinan besar manajer peduli tentang hal-hal seperti seberapa sering dan aman Anda dapat merilis ke pasar.

— Aaronaught