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.