Haruskah saya sengaja merusak build ketika bug ditemukan dalam produksi?


410

Tampaknya masuk akal bagi saya bahwa jika bug serius ditemukan dalam produksi oleh pengguna akhir, tes unit gagal harus ditambahkan untuk menutupi bug itu, sehingga dengan sengaja merusak build sampai bug diperbaiki. Alasan saya untuk ini adalah bahwa build seharusnya gagal selama ini , tetapi bukan karena tidak cukupnya cakupan tes otomatis.

Beberapa kolega saya tidak setuju mengatakan bahwa unit test yang gagal tidak boleh diperiksa. Saya setuju dengan sudut pandang ini dalam hal praktik TDD normal, tapi saya pikir bug produksi harus ditangani secara berbeda - setelah semua mengapa Anda ingin mengizinkan membangun untuk sukses dengan cacat yang dikenal?

Apakah ada orang lain yang memiliki strategi terbukti untuk menangani skenario ini? Saya mengerti bahwa dengan sengaja merusak bangunan bisa mengganggu anggota tim lainnya, tetapi itu sepenuhnya tergantung pada bagaimana Anda menggunakan cabang.


75
+1; pertanyaan yang sangat provokatif. Saya bisa melihat kedua sisi.
Carl Manaster

28
Anda menggunakan istilah "the build" untuk memasukkan "the test", yang bukan merupakan pemahaman universal.
Jay Bazuzi

19
Jika Anda melakukan TDD, Anda akan menulis tes gagal, lalu perbaiki kode lalu check-in . Dengan demikian Anda menghindari bangunan yang rusak.
dietbuddha

7
Dengan logika yang sama Anda harus mematikan instance langsung klien sampai Anda memperbaiki masalah. Tidak, Anda tidak harus merusak bangunan. Biarkan pengembang yang menangani bug menambahkan tes unit dan kode berubah bersama. Tidak perlu mematikan seluruh proses.
Thanos Papathanasiou

Jawaban:


412

Strategi kami adalah:

Periksa dalam tes yang gagal, tetapi beri catatan dengan @Ignore("fails because of Bug #1234").

Dengan begitu, tes ada di sana, tetapi build tidak rusak.

Tentu saja Anda mencatat tes yang diabaikan dalam bug db, sehingga @Ignoredihapus setelah tes diperbaiki. Ini juga berfungsi sebagai pemeriksaan mudah untuk perbaikan bug.

Inti dari kegagalan dalam membangun tes yang gagal bukanlah untuk entah bagaimana membuat tim di bawah tekanan - itu untuk mengingatkan mereka akan masalah. Setelah masalah diidentifikasi dan diajukan dalam bug DB, tidak ada gunanya menjalankan tes untuk setiap build - Anda tahu bahwa itu akan gagal.

Tentu saja bug itu harus diperbaiki. Tetapi menjadwalkan perbaikan adalah keputusan bisnis, dan dengan demikian tidak benar-benar menjadi perhatian dev ... Bagi saya, sekali bug diajukan dalam bug DB, itu bukan lagi masalah saya, sampai pelanggan / pemilik produk memberi tahu saya bahwa mereka ingin memperbaikinya. .


150
+1 Saya pikir Anda sudah mulai berpikir dengan "menjadwalkan perbaikan adalah keputusan bisnis" - sebagai pengembang itu bukan keputusan penilaian saya untuk memutuskan apakah bug merusak build.
MattDavey

22
Saya pikir ini adalah solusi yang sangat masuk akal. Terutama jika orang berikutnya memeriksa beberapa kode minor, tiba-tiba mendapat pemberitahuan "gagal tes" dan berpikir itu adalah sesuatu yang telah ia lakukan.
Holger

14
"Bagi saya, sekali bug dimasukkan dalam bug DB, itu bukan lagi masalah saya" ... +1
Jake Berger

20
@anon Exept di Toyota. Seorang pekerja garis melihat ada kerusakan, kemudian menarik kabel andon dan seluruh pabrik berhenti dan manajemen datang dan saluran tidak dimulai kembali sampai masalahnya diperbaiki. Google Andon Cord. Itu bukan konsep baru. lihat: startuplessonslearned.com/2008/09/...
Christopher Mahan

4
@ AndresJaanTack: Ini tentu saja tergantung pada metodologi Anda, tetapi secara umum saya tidak setuju. Setidaknya dalam pengaturan bisnis, pekerjaan penjadwalan adalah keputusan bisnis - dan itu termasuk perbaikan bug . Kadang-kadang, fitur baru (atau dirilis pada tanggal tertentu) mungkin lebih berharga daripada memperbaiki bug (kecil) - dalam hal ini perbaikan bug harus ditangguhkan. "Memperbaiki bug sekarang" akan tidak sesuai dalam situasi itu, karena menunda pekerjaan yang lebih penting.
sleske

106

Mengapa Anda ingin membiarkan bangunan berhasil dengan cacat yang diketahui?

Karena terkadang, Anda memiliki batasan waktu. Atau bug itu sangat kecil sehingga tidak layak menunda pengiriman produk selama beberapa hari yang dibutuhkan untuk unit test dan memperbaikinya.

Juga, apa gunanya melanggar build secara sengaja setiap kali Anda menemukan bug? Jika Anda menemukannya, perbaiki (atau berikan kepada orang yang akan memperbaikinya), tanpa mengganggu seluruh tim Anda. Jika Anda ingin mengingat untuk memperbaiki bug, maka Anda harus menandainya sebagai sangat penting dalam sistem pelacakan bug Anda.


Saya mengerti maksud Anda, dan secara umum saya setuju - tetapi dalam hal ini kita berbicara tentang bug serius yang membuatnya menjadi produksi dan ditemui oleh pengguna akhir: s
MattDavey

3
Lihat paragraf kedua dari jawaban saya.
Arseni Mourzenko

8
Saya mengerti, saya pikir intinya dirangkum dalam paragraf pertama Anda - bukan tanggung jawab pengembang untuk menilai keseriusan bug, atau apakah itu show-stopper, itu keputusan untuk bisnis yang lebih luas.
MattDavey

4
Pertanyaannya adalah apa prioritas bug ini? Bisa jadi OMG MEMPERBAIKI SEKARANG JAUH bisa jadi itu menjengkelkan kita harus memperbaikinya di beberapa titik itu bisa menjadi sesuatu di tengah. Tetapi tidak semua bug akan terkena di tempat yang sama pada spektrum itu.
Zachary K

55

Tes ada untuk memastikan bahwa Anda tidak (kembali) memperkenalkan masalah. Daftar tes yang gagal bukanlah pengganti sistem pelacakan bug. Ada beberapa validitas dalam POV bahwa tes gagal tidak hanya indikasi bug, mereka juga merupakan indikasi kegagalan proses pengembangan (dari kecerobohan hingga ketergantungan yang diidentifikasi dengan buruk).


20
"daftar tes yang gagal bukan pengganti sistem pelacakan bug" +1, juga poin yang sangat bagus :)
MattDavey

1
Saya sarankan untuk memiliki tes unit regresi masukkan basis kode sebagai bagian dari perbaikan bug, bukan sebelumnya.
yrk

6
@yarek: Tes regresi dapat masuk ke basis kode kapan saja, mereka hanya perlu diabaikan sampai bug diperbaiki. Saya biasanya mengembangkannya saat mendiagnosis masalah, karena mereka kemudian dapat berfungsi ganda sebagai bantuan debugging.
sleske

Ini adalah contoh yang baik mengapa "melanggar pembangunan" menjadi bagian beracun dari tempat kerja di mana CI beralih menjadi "Pembangunan yang Didorong oleh Blame". Saya telah duduk dalam banyak pertemuan di mana PHB mulai mengomel tentang "kecerobohan" seolah-olah itu sebabnya bangunan rusak. Dalam lingkungan seperti itu, Anda hampir tidak akan dengan sengaja memeriksa sesuatu yang merusak bangunan. Kalau tidak, PHB akan marah. Hancurkan bangunan, kenakan kerucut rasa malu. Latihan yang sangat buruk.
Warren P

@ WarrenP, kadang-kadang ada masalah lain, tapi mari kita perjelas, kecerobohan adalah alasan pertama mengapa build rusak. Jika Anda tahu ada sesuatu yang merusak build, mengapa harus check in?
Pemrogram

23

"Break the build" berarti mencegah pembangunan agar tidak berhasil diselesaikan . Tes gagal tidak melakukan itu. Ini merupakan indikasi bahwa cacat bawaan telah diketahui, yang mana sebenarnya tepat.

Kebanyakan server membangun melacak status tes dari waktu ke waktu, dan akan menetapkan klasifikasi yang berbeda untuk tes yang telah gagal sejak ditambahkan vs regresi (tes yang digunakan untuk lulus dan tidak lagi melakukannya), dan juga mendeteksi revisi di mana regresi terjadi.


12
Ini tidak selalu benar, sering tim menganggap tes yang gagal sebagai bangunan yang rusak - bahkan sebagian besar tim yang saya lihat belakangan ini melakukan (Ini adalah praktik tangkas khas). Dengan tim yang paling gesit, tes yang gagal adalah kasus di mana Anda menghentikan garis - seluruh tim menyerang masalah dan menyelesaikannya. Saya kira saya bisa menganggap posting Anda berarti bahwa respons harus didasarkan pada praktik Anda, dalam hal ini benar-benar akurat.
Bill K

2
Saya selalu menganggap tes gagal berarti build gagal.
John Saunders

@ JohnSaunders: Tapi bukan itu artinya. Seperti yang saya katakan dalam jawaban saya, itu berarti "build telah mengetahui cacatnya".
Ben Voigt

1
@i kata Anda tidak ada tes? dimana kamu mendapatkan itu? Maksud saya, langkah pertama saya setelah menemukan bug bukanlah untuk mencegah agar build tidak berhasil, tetapi untuk membuat laporan bug yang terperinci. Ketika bug diperbaiki, pertama-tama harus ada unit test yang gagal.
John Saunders

1
Saya memiliki sedikit masalah dengan pembuatan langsung dari tes yang gagal. Aku hanya tidak ingin itu masuk ke set tes yang akan berjalan pada saat membangun. Saya juga ingin pengembang yang memperbaiki bug dapat mengabaikan tes itu. Di sebagian besar tempat saya bekerja, orang-orang yang membuat laporan bug tidak akan membuat tes unit.
John Saunders

16

Saya berpendapat bahwa tes gagal harus ditambahkan, tetapi tidak secara eksplisit sebagai "tes gagal."

Seperti @BenVoigt tunjukkan dalam jawabannya , tes gagal tidak selalu "merusak build." Saya kira terminologinya dapat bervariasi dari satu tim ke tim lainnya, tetapi kodenya masih dikompilasi dan produk masih dapat dikirimkan dengan tes yang gagal.

Yang harus Anda tanyakan pada diri sendiri dalam situasi ini adalah,

Apa ujian yang ingin dicapai?

Jika tes ada di sana hanya untuk membuat semua orang merasa nyaman dengan kode tersebut, maka menambahkan tes gagal hanya untuk membuat semua orang merasa buruk tentang kode itu tidak produktif. Namun, seberapa produktifkah tes itu?

Pernyataan saya adalah bahwa tes harus mencerminkan persyaratan bisnis . Jadi, jika "bug" telah ditemukan yang menunjukkan persyaratan tidak terpenuhi dengan benar, maka itu juga merupakan indikasi bahwa tes tidak benar atau sepenuhnya mencerminkan persyaratan bisnis.

Itulah bug yang harus diperbaiki terlebih dahulu. Anda tidak "menambahkan tes yang gagal." Anda mengoreksi tes untuk menjadi refleksi yang lebih akurat dari persyaratan bisnis. Jika kode kemudian gagal lulus tes itu, itu hal yang baik. Itu berarti tes sedang melakukan pekerjaan mereka.

Prioritas memperbaiki kode harus ditentukan oleh bisnis. Tetapi sampai tes diperbaiki, dapatkah prioritas itu benar-benar ditentukan? Bisnis harus dipersenjatai dengan pengetahuan tentang apa sebenarnya yang gagal, bagaimana itu gagal, dan mengapa ia gagal untuk membuat keputusan berdasarkan prioritas. Tes harus menunjukkan ini.

Memiliki tes yang tidak sepenuhnya lulus bukanlah hal yang buruk. Ini menciptakan artefak besar dari masalah yang diketahui untuk diprioritaskan dan ditangani sesuai. Namun, memiliki tes yang tidak sepenuhnya diuji adalah masalah. Ini mempertanyakan nilai dari tes itu sendiri.

Untuk mengatakannya dengan cara lain ... Bangunannya sudah rusak. Yang Anda putuskan adalah apakah akan memperhatikan fakta itu atau tidak.


1
Pernyataan Anda salah, tes unit tidak perlu memetakan langsung ke persyaratan bisnis, sedangkan tes fungsional atau end-to-end mungkin dilakukan, tetapi OP berbicara tentang tes unit / TDD.
John Buchanan

@JohnBuchanan: Apa tes yang dimaksudkan untuk memvalidasi, jika tidak bahwa perangkat lunak melakukan apa yang seharusnya dilakukan? (Yaitu, bahwa itu memenuhi persyaratan.) Ada, seperti yang Anda sebutkan, bentuk-bentuk tes lain di luar tes unit. Tetapi saya gagal melihat nilai dalam unit test yang tidak memvalidasi bahwa perangkat lunak itu memenuhi kebutuhan bisnis.
David

1
@JohnBuchanan - dia tidak mengatakan "tes ADALAH cerminan dari persyaratan bisnis", katanya "HARUS MENJADI". Itu benar, tapi masih bisa diperdebatkan. Anda benar dalam mengklaim bahwa ini tidak selalu terjadi - beberapa orang menulis tes unit yang tidak memetakan persyaratan bisnis - meskipun (menurut saya) mereka salah melakukannya. Jika Anda ingin mengklaim bahwa pernyataan David salah, Anda dapat mengatakan sesuatu tentang mengapa Anda berpikir demikian.
Dawood ibn Kareem

13

Di tim otomasi pengujian kami, kami memeriksa tes yang gagal asalkan gagal karena cacat pada produk alih-alih cacat dalam pengujian. Dengan begitu kita punya bukti untuk tim dev bahwa hei, mereka melanggarnya. Breaking build sangat disukai, tetapi itu tidak sama dengan memeriksa dalam tes yang dapat dikompilasi tetapi gagal.


4
Saya pikir ide @ MattDavey sangat bagus, dan saya telah membantahnya di masa lalu. Saya selalu bertemu dengan tembok batu perlawanan - "Anda seharusnya tidak pernah merusak bangunan!". Gagasan bahwa bangunan sudah rusak dalam situasi ini tampaknya mustahil untuk dipahami orang. Sayangnya, ini hanyalah kasus lain di mana ide yang bagus (pengujian otomatis dan bangunan bersih) telah beralih ke praktik pemujaan kargo yang penganutnya mengetahui aturan tetapi bukan alasannya.
Tom Anderson

3
Satu ide yang saya temukan adalah bahwa tim QA (jika mereka cukup teknis untuk menulis tes) harus diizinkan untuk menulis tes gagal untuk bug, dan memeriksanya. Obsesi pengembang dengan bilah hijau kemudian akan menghasilkan memprioritaskan memperbaiki bug daripada menambahkan fitur, yang merupakan cara yang benar untuk melakukan pengembangan.
Tom Anderson

Tetapi ini seharusnya tidak menjadi unit test yang akan berjalan selama build. Jika lingkungan Anda mengandung sistem manajemen pengujian untuk QA (seperti Microsoft Test Manager), maka tentu saja, satu atau lebih kasus uji harus ditambahkan dan ditautkan ke bug, tetapi ini tidak akan mencegah build dari berhasil - itu hanya akan menjadi tes hal yang harus dilewati sebelum bug dianggap "Selesai".
John Saunders

7

Menulis tes yang Anda tahu akan gagal sampai bug diperbaiki adalah ide yang baik, itu dasar dari TDD.

Menghancurkan bangunan adalah ide yang buruk. Mengapa? Karena itu berarti tidak ada yang bisa bergerak sampai diperbaiki. Ini pada dasarnya memblokir semua aspek pembangunan lainnya.

Contoh 1
Bagaimana jika aplikasi Anda sangat besar, dengan banyak komponen? Bagaimana jika komponen-komponen itu dikerjakan oleh tim lain dengan siklus rilis mereka sendiri? Sulit! Mereka harus menunggu untuk memperbaiki bug Anda!

Contoh 2
Bagaimana jika bug pertama sulit untuk diperbaiki dan Anda menemukan bug lain dengan prioritas lebih tinggi? Apakah Anda juga merusak build untuk bug kedua? Sekarang Anda tidak dapat membangun sampai keduanya diperbaiki. Anda telah membuat ketergantungan buatan.

Tidak ada alasan logis mengapa gagal dalam ujian harus menghentikan pembangunan. Ini adalah keputusan yang perlu dibuat oleh tim pengembang (mungkin dengan diskusi manajemen) yang mempertimbangkan pro dan kontra dari merilis build dengan bug yang diketahui. Ini sangat umum dalam pengembangan perangkat lunak, hampir semua perangkat lunak utama dirilis dengan setidaknya beberapa masalah yang diketahui.


5

Itu tergantung pada peran tes yang seharusnya dimainkan dan bagaimana hasil mereka seharusnya mempengaruhi sistem pembangunan / proses yang diadopsi. Pemahaman saya tentang melanggar build adalah sama dengan Ben, dan pada saat yang sama kita seharusnya tidak secara sengaja memeriksa kode yang merusak tes yang ada. Jika tes-tes itu masuk "nanti", mungkin "oke" untuk mengabaikannya hanya untuk membuatnya tidak terlalu mengganggu bagi orang lain, tetapi saya menemukan praktik mengabaikan tes gagal (sehingga tampaknya lulus) agak mengganggu (terutama begitu untuk tes unit), kecuali ada cara untuk menunjukkan tes seperti tidak merah atau hijau.


"kecuali jika ada cara untuk menunjukkan tes seperti bukan merah atau hijau" Hanya sebagai catatan: Kebanyakan kerangka kerja unit pengujian membedakan tes merah, hijau dan diabaikan. Setidaknya JUnit dan TestNG melakukan (mereka melaporkan "xx test, x gagal, x diabaikan").
sleske

@sleske yang akan ideal, saya hanya ingin memastikan bahwa mengabaikan kegagalan tidak secara otomatis berubah menjadi sukses
prusswan

Apakah tidak ada bangunan KUNING? (Merah / Hijau / Kuning) di Hudson / Jenkins, Cruise Control, dan semua biggies lainnya?
Warren P

@ Warren P berfungsi ketika orang mengabaikan tes dengan benar, tetapi beberapa mengabaikan tes dengan membuatnya hijau
prusswan

5

Itu tergantung pada bug, tentu saja, tetapi umumnya jika ada kesalahan yang tidak teridentifikasi selama pengujian manual atau otomatis, maka itu menyiratkan ada kesenjangan dalam cakupan Anda. Saya pasti akan mendorong mencari tahu penyebab utama dan menampar kasus uji unit di atas masalah.

Jika ini merupakan masalah produksi yang direncanakan untuk perbaikan terbaru dari cabang pemeliharaan, Anda juga perlu memastikan bahwa perbaikan tersebut bekerja pada jalur utama, dan bahwa pengembang tidak dapat secara salah menerbangkan perbaikan dengan resolusi konflik penggabungan yang terlalu bersemangat. .

Selain itu, tergantung pada kebijakan rilis Anda, keberadaan tes unit yang baru diperbarui dapat membantu mengonfirmasi bahwa pengembang telah benar-benar menyelesaikan masalah, bukan hanya mengubahnya [(masalah atau tes?)], Meskipun ini tergantung pada penyandian kode. persyaratan yang benar dalam pengujian unit baru.


5

Satu masalah dengan menambahkan tes tahu-gagal ke build adalah bahwa tim Anda mungkin terbiasa mengabaikan tes gagal karena mereka berharap build gagal. Itu tergantung pada sistem build Anda, tetapi jika tes gagal tidak selalu berarti "sesuatu yang baru saja rusak" maka mudah untuk kurang memperhatikan tes gagal.

Anda tidak ingin membantu tim Anda masuk ke dalam pola pikir itu.

Jadi saya setuju dengan sleske bahwa Anda harus menambahkan tes, tetapi tandai sebagai 'diabaikan' untuk tujuan pembuatan otomatis, sampai bug diperbaiki.


1
Perangkat lunak pengujian Anda harus memberi tahu Anda ketika ada sesuatu yang baru rusak, vs tes yang gagal sebelumnya.
Ben Voigt

4

Meskipun saya pikir Anda harus dengan cara tertentu 'memeriksa' bug sebagai tes, sehingga ketika Anda memperbaikinya tidak terjadi lagi, dan dalam beberapa cara memprioritaskannya, saya pikir yang terbaik adalah tidak merusak build (/ tes) . Alasannya adalah bahwa selanjutnya komitmen membangun akan disembunyikan di balik tes Anda yang rusak. Jadi dengan memeriksa tes yang rusak untuk bug ini Anda menuntut agar seluruh tim mengesampingkan pekerjaan mereka untuk memperbaiki bug ini. Jika itu tidak terjadi, Anda mungkin berakhir dengan melanggar komitmen yang tidak dapat dilacak seperti itu.

Karena itu saya akan mengatakan lebih baik untuk menjadikannya sebagai tes yang tertunda, dan menjadikannya prioritas dalam tim Anda untuk tidak memiliki tes yang tertunda.


4

Pilihan lain adalah memeriksa tes gagal ke cabang terpisah di sistem kontrol sumber Anda. Tergantung pada praktik Anda, ini mungkin layak atau tidak. Kami terkadang membuka cabang baru untuk pekerjaan yang sedang berlangsung, seperti memperbaiki bug yang tidak sepele.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.