Haruskah kita selalu menguji bug saat memperbaikinya?


29

Saat mengoreksi bug, disarankan di mana saya bekerja untuk pertama kali menulis tes yang gagal dengan bug yang diberikan, dan kemudian memperbaiki kode sampai tes berlalu. Ini mengikuti praktik TDD, dan seharusnya menjadi praktik yang baik, tetapi saya perhatikan cenderung menghasilkan tes samar yang mendekati implementasi.

Misalnya, kami memiliki masalah ketika pekerjaan dikirim, mencapai kondisi tertentu, dibatalkan, dan dicoba lagi. Untuk mereproduksi bug ini, tes besar-besaran ditulis dengan sinkronisasi utas di dalamnya, banyak ejekan dan semacamnya ... Itu berhasil, tapi sekarang saya refactoring kode, saya merasa sangat tergoda untuk hanya menghapus mammoth ini, karena itu benar-benar membutuhkan banyak pekerjaan (lagi) agar sesuai dengan desain baru. Dan itu hanya menguji satu fitur kecil dalam satu kasus spesifik.

Karena itu pertanyaan saya: bagaimana Anda menguji bug yang sulit direproduksi? Bagaimana Anda menghindari membuat hal-hal yang menguji implementasi, dan merusak refactoring dan keterbacaan?


Apakah case error itu relevan dengan desain baru? Bagi saya bagian dari desain baru adalah untuk meningkatkan keandalan desain, jadi Anda mungkin dapat menggunakannya untuk membenarkan menghapus test case ini jika jenis bug ini ada hubungannya dengan kesalahan dalam desain asli.
Thymine

refactor adalah tentang sesuatu yang lain, dan masih mungkin dalam desain baru untuk sedikit memodifikasi kode dan memperkenalkan kembali bug, yang merupakan tes yang ditonton. Saya kira alternatif untuk tes akan menjadi komentar dalam kode yang mengatakan "jangan bercinta dengan ini", tapi sepertinya itu hal yang salah untuk dilakukan: p
Zonko

1
jika terlalu rumit untuk unittest menjadikannya bagian dari uji integrasi
ratchet freak

Kedengarannya seperti ini membutuhkan tes integrasi dan bukan tes unit. Berdasarkan fakta bahwa Anda sangat mengejek. Aturan umum yang saya lihat adalah bahwa Anda tidak menguji kode yang berbicara ke komponen di luar basis kode Anda (berbicara ke database, membaca dari sistem file, dll) yang kedengarannya seperti apa yang dilakukannya.
Lucas

Jawaban:


27

Ya, secara umum Anda harus . Seperti halnya semua pedoman, Anda harus menggunakan penilaian terbaik Anda saat menjalankannya terhadap pedoman lain. Untuk skenario ini, tingkat keparahan bug perlu ditimbang terhadap pekerjaan yang diperlukan untuk mengimplementasikan tes dan kualitas tes yang ditargetkan untuk masalah bisnis dan menangkap regresi kondisi bug.

Saya cenderung lebih suka menulis tes daripada tidak, karena gangguan untuk menjalankan bug cenderung memiliki lebih banyak overhead daripada hanya mengembangkan dan mempertahankan unit test.


Saya akan menambahkan lebih banyak penekanan pada hal ini dan menyatakan bahwa di dunia yang ideal itu hanya akan dianggap sebagai bug jika ada unit test yang gagal, tetapi +1 untuk huruf miring dan mencatat bahwa kebutuhan bisnis harus menang.
Joshua Drake

2
well, memang, pada akhirnya itu semua tentang keseimbangan antara waktu yang dibutuhkan untuk mempertahankan tes vs waktu yang dibutuhkan untuk noob untuk mendeteksi dan memperbaiki bug jika itu terjadi lagi.
Zonko

Saya juga ingin menggeneralisasi tes sehingga tidak hanya menguji aborsi dan mencoba ulang pekerjaan ketika mencapai satu keadaan tertentu, tetapi lebih tepatnya tes membatalkan dan mencoba ulang di setiap negara tempat pekerjaan.
Pro Lama

+1 untuk "karena gangguan untuk menjalankan bug cenderung memiliki lebih banyak overhead daripada hanya mengembangkan dan mempertahankan unit test."
Peter K.

16

Saya pikir praktik terbaik - yang membuat saya malu untuk mengakui bahwa saya tidak sering mengikuti - adalah membuat tes sistem atau integrasi yang menunjukkan masalah yang diamati dalam produksi, kemudian penelitian untuk menemukan unit yang bertanggung jawab atas masalah tersebut, dan kemudian menulis tes unit untuk unit-unit yang menunjukkan masalah di tingkat unit . Setelah Anda memiliki unit test, perbaiki unit, dan jalankan semua tes. Pada titik ini, mungkin bijaksana untuk membuang tes asli - karena mungkin rapuh dan / atau lambat - tetapi simpan unit tes di suite otomatis Anda demi regresi dan cakupan.


7

Praktik menulis tes untuk mengidentifikasi cacat adalah ide yang baik, karena memungkinkan Anda untuk mengidentifikasi langkah-langkah apa yang diperlukan untuk mereproduksi cacat dan memverifikasi bahwa itu sudah diperbaiki. Selain itu, pengujian ini dapat dijalankan sebagai bagian dari pengujian asap atau pengujian regresi untuk memastikan bahwa perubahan di kemudian hari tidak memasukkan kembali cacat lama ke dalam sistem.

Hal pertama yang perlu dipertimbangkan adalah tingkat tes yang dibutuhkan. Mungkin tes untuk memverifikasi perbaikan akan lebih tepat di tingkat sistem, atau mungkin bahkan tes penerimaan yang dilakukan secara manual. Saya pikir lebih penting untuk memiliki tes yang didokumentasikan dan dikelola, terlepas dari bagaimana itu diterapkan secara khusus.

Sejauh bagaimana refactoring memengaruhi tes, itu tergantung pada karakteristik spesifik. Dalam beberapa kasus, refactoring (atau segala jenis pekerjaan, seperti fitur baru) dapat membuat tes tidak lagi diperlukan. Masalahnya, seperti yang awalnya terjadi, mungkin tidak lagi mungkin. Dalam hal ini, mungkin bijaksana untuk menghapus tes dari tes yang mungkin untuk membuat proses pengujian Anda (otomatis atau manual) lebih ramping. Dalam kasus lain, ada beberapa metode untuk melakukan pengujian dan memverifikasi fitur pada tingkat yang berbeda mungkin lebih tepat. Jika fitur ini kecil, mungkin pengujian tidak lagi diperlukan sama sekali.

Anda juga dapat mempertimbangkan tidak hanya mengandalkan pengujian, tetapi juga mencatat. Misalnya, menangkap informasi pada saat run-time (dengan berbagai tingkat verbositas tergantung pada lingkungan - lebih banyak bertele-tele selama pengujian, kurang bertele-tele selama penyebaran), membuat profil aplikasi, menangkap kesedihan dari kondisi sistem saat ini. Jika Anda dapat menemukan pemicu umum untuk masalah tersebut, Anda dapat menggunakannya untuk memandu pengujian di semua tingkatan.


5

Ya kamu harus.

Tulis tes unit untuk basis kode yang ada. Saat memperbaiki bug, Anda perlu memastikan bahwa unit test Anda gagal - ini akan memberi Anda keyakinan bahwa Anda memang sedang mengerjakan bug. Anda kemudian perlu faktor ulang dan lulus ujian dengan memperbaiki bug.

Namun ini bukan praktik TDD. Dalam tes TDD, buat desain Anda, tetapi dalam kasus Anda desainnya sudah diputuskan.

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.