Tes Unit Lama / Warisan Patah

Saya bekerja untuk perusahaan besar dan saya bertanggung jawab untuk aplikasi java besar dengan ribuan tes junit. Sejak saya pindah ke peran ini, ada 200-300 tes yang gagal (kemungkinan rusak selama bertahun-tahun). Tes sudah tua dan rapuh dan mereka berantakan ketergantungan spageti yang biasanya diakhiri dengan data kotak pasir langsung.

Sasaran saya adalah 100% lulus tes sehingga kami dapat merusak build pada kegagalan unit test, tetapi saya tidak dapat melakukannya sampai saya mengatasi tes yang rusak. Saya memiliki anggaran yang sangat sedikit karena anggaran pemeliharaan terutama untuk dukungan, tetapi tim saya telah mengidentifikasi dan memperbaiki tes buah tergantung rendah (kebanyakan masalah konfigurasi / sumber daya lokal) dan kami turun ke 30-40 tes yang benar-benar jelek.

Apa opini tentang praktik terbaik? Saya tidak berpikir tes itu berharga, tetapi saya juga tidak tahu apa yang mereka uji atau mengapa mereka tidak bekerja tanpa menggali, yang membutuhkan waktu dan uang yang mungkin tidak kita miliki.

Saya pikir kita harus mendokumentasikan status tes yang rusak dengan apa pun yang kita ketahui, lalu hapus atau abaikan tes yang rusak sepenuhnya dan masukkan bug / item kerja dengan prioritas lebih rendah untuk menyelidiki dan memperbaikinya. Kami kemudian akan berada di 100% dan mulai mendapatkan nilai nyata dari tes lain dan jika kami memiliki rejeki pemeliharaan / refactoring kami akan dapat mengambilnya lagi.

Apa yang akan menjadi pendekatan terbaik?

Sunting: Saya pikir ini adalah pertanyaan yang berbeda dari pertanyaan ini karena saya memiliki arahan yang jelas untuk tes yang harus kami tulis ke depan, tetapi saya mewarisi warisan yang gagal untuk diatasi sebelum rangkaian tes yang sekarang menjadi bermakna.

Apa yang akan saya lakukan adalah pertama-tama menonaktifkan tes yang gagal-dan-selalu-gagal.

Jadikan itu ujian gagal.

Saat Anda menyelidiki, Anda mungkin bisa bertanya kepada orang-orang yang telah lama bersama perusahaan Anda tentang mereka, mungkin ada banyak pengetahuan kesukuan tentang mereka yang dapat Anda dokumentasikan / tangkap. Mungkin dari log VCS Anda. "Oh, tes itu selalu gagal sejak kami memutakhirkan ke X" atau informasi lain bisa berguna.

Setelah Anda tahu fungsi apa yang diuji, Anda dapat menentukan:

• Apakah kita peduli dengan ini yang sedang diuji
• Seberapa penting hal ini untuk diuji

Dan kemudian buat daftar prioritas.

Kemungkinan tidak ada dalam daftar ini yang cukup penting untuk mendapatkan lebih banyak waktu kemudian karena sudah diabaikan selama bertahun-tahun. Jadi saya tidak akan menghabiskan terlalu banyak waktu / sumber daya untuk mendokumentasikan dan menganalisis semua tes yang rusak ini.

Saya akan melakukan hal berikut:

1. Coba tentukan dengan tepat apa yang coba divalidasi oleh tes gagal.

2. Triage - jika beberapa tes mencoba menguji hal-hal yang tidak penting seperti (dunia lama) dunia, hapuslah. Jika Anda menyadari bahwa beberapa dari mereka mencoba untuk memvalidasi sesuatu yang penting, cobalah untuk menentukan apakah tes tersebut melakukannya dengan benar. Jika mereka melakukan pengujian yang salah, lakukan pengujian dengan benar.

3. Perbaiki apa pun yang salah dengan kode produksi Anda sekarang setelah Anda memiliki tes yang bagus.

Ingat akuntansi, setiap baris kode adalah kewajiban, tetapi mungkin dinilai secara tidak benar sebagai aset. The deletekunci dapat menciptakan banyak nilai untuk perusahaan Anda.

200-300 tes rusak (kemungkinan rusak selama bertahun-tahun).

Aduh! Saya menghadapi situasi yang sama sekali tetapi dengan seperti 7 tes gagal di mana tim mulai mengabaikan fakta bahwa mereka gagal selama berbulan-bulan karena mentalitas "selalu-krisis".

Sasaran saya adalah 100% lulus tes sehingga kami dapat merusak build pada kegagalan unit test, tetapi saya tidak dapat melakukannya sampai saya mengatasi tes yang rusak.

Saya terobsesi dengan tujuan yang sama meskipun saya hanya seorang pengembang junior di tim karena saya melihat tumpukan di mana lebih banyak tes gagal selama berbulan-bulan. Saya ingin kita mengubah itu dari "peringatan" menjadi kesalahan build (mungkin agak menjengkelkan ke seluruh tim).

Saya pikir kita harus mendokumentasikan status tes yang rusak dengan apa pun yang kita ketahui, lalu hapus atau abaikan tes yang rusak sepenuhnya dan masukkan bug / item kerja dengan prioritas lebih rendah untuk menyelidiki dan memperbaikinya. Kami kemudian akan berada di 100% dan mulai mendapatkan nilai nyata dari tes lain dan jika kami memiliki rejeki pemeliharaan / refactoring kami akan dapat mengambilnya lagi.

Ini juga pikiran saya. Anda dapat menonaktifkan sementara semua tes yang salah ini dan secara perlahan mengunjunginya dan memperbaikinya seiring waktu. Sangat penting untuk menjadwalkan perbaikan tersebut jika Anda menganggapnya sangat penting, bahkan jika prioritasnya rendah, karena mudah untuk barang-barang seperti itu tidak diperbaiki. Prioritas saya adalah memastikan tidak ada tes baru yang gagal.

Seperti peringatan apa pun, jika mereka tidak merusak bangunan, mereka cenderung menumpuk dengan cepat. Ini mengasumsikan jenis tim yang dinamis di mana kebiasaan mengabaikan peringatan (gagal dalam hal ini) dapat dengan cepat menyebabkan lebih banyak peringatan yang diperkenalkan, dan mengurangi godaan untuk menjaga agar peringatan tersebut tetap nol.

Sebuah tim yang sangat berhati-hati mungkin tidak mengalami masalah ini dan menghindari memperkenalkan peringatan baru (kegagalan baru dalam tes), tapi itu pasti lebih aman untuk menjadi sedikit lebih berat tangan dan menggunakan strategi pencegahan dengan mengubah ini menjadi kesalahan yang harus diperbaiki sebelum suatu proses penggabungan.

Jadi saran saya sama dengan saran Anda (meskipun hanya pendapat yang kuat - mungkin agak bisa mendukungnya dengan metrik dan jawaban yang lebih ilmiah). Nonaktifkan tes lama itu, dan letakkan pada jadwal untuk akhirnya memperbaikinya. Prioritas pertama adalah memastikan bahwa masalah ini tidak menumpuk dan mulai memburuk dengan memastikan tes yang saat ini berhasil pada akhirnya tidak akan diabaikan jika mereka mulai gagal.

Di satu sisi Anda beruntung. Lebih baik memiliki tes yang gagal dan tidak seharusnya (mereka memberi Anda peringatan setidaknya bahwa ada sesuatu yang salah) daripada memiliki tes yang lulus dan tidak seharusnya (yang memberi Anda rasa aman palsu).
Tentu saja jika Anda memiliki yang pertama, kemungkinan besar Anda memiliki yang pertama juga (jadi tes yang lulus tetapi harus gagal).

Seperti yang sudah dinyatakan, untuk saat ini nonaktifkan tes yang gagal tetapi minta mereka mencetak pesan di log pengujian Anda sebagai pengingat konstan tentang mereka.
Tetapi Anda pasti harus menemukan sumber daya untuk memeriksa seluruh rangkaian tes Anda untuk menemukan dan membuang tes yang lulus dan tidak boleh, karena masing-masing dari mereka berarti ada bug dalam kode Anda yang saat ini tidak Anda deteksi dalam Anda siklus tes.

Dengan awan gelap yang tergantung pada basis kode, Anda mungkin bisa mendapatkan anggaran untuk ulasan lengkap tes Anda, jika Anda memainkannya dengan benar dan jangan hanya memberi tahu Anda, Anda berpikir beberapa tes harus dilihat karena tampaknya gagal ketika seharusnya tidak, tetapi Anda tidak percaya bahwa tes Anda mendeteksi kesalahan dalam kode Anda dengan benar, bahwa set tes tidak dapat dipercaya untuk melakukan tugasnya.
Ketika saya melakukan itu di perusahaan sebelumnya saya bekerja untuk review seperti itu menemukan bahwa ratusan tes ditulis dengan asumsi yang salah tentang apa yang harus dilakukan kode, mengarah ke kode (yang ditulis menggunakan asumsi yang salah sama) lulus tes ketika seharusnya tidak. Memperbaiki ini memecahkan banyak bug kasus sudut buruk yang (sementara sebagian besar tidak kritis) dapat menurunkan beberapa sistem penting.

Uji unit yang gagal harus menyebabkan bangunan rusak. Baik bagi Anda untuk menyadarinya dan menetapkan tujuan itu. Pikiran manusia hampir tidak dapat mengabaikan apa pun lebih lengkap daripada sumber alarm palsu yang terus-menerus .

Buang tes-tes ini dan jangan melihat ke belakang. Jika mereka telah gagal selama bertahun-tahun dan belum ditangani sekarang maka mereka bukan prioritas.

Adapun pengetahuan kesukuan, jika orang-orang dengan pengetahuan kesukuan masih ada, mereka seharusnya sudah memperbaiki tes yang gagal sekarang. Jika tidak, maka sekali lagi, ini bukan prioritas.

Jika tidak ada pengetahuan kesukuan, Anda dan tim Anda harus memiliki logika. Tes yang gagal mungkin lebih menyesatkan daripada membantu - dunia mungkin telah pindah.

Buat tes baru yang relevan dan mulai menulis kode yang bagus.