Bagaimana cara menghadapi sejumlah besar tes gagal? [Tutup]

Saya sedang mengerjakan pengembangan proyek lama yang ditulis di Jawa. Kami memiliki lebih dari 10 juta LOC dan, lebih buruk lagi, lebih dari 4000 tes fungsional.

Tes, dijadwalkan oleh Hudson, gagal seperti orang gila dengan setiap perubahan kode yang lebih besar. Verifikasi kegagalan pengujian - jika ini merupakan masalah pada produk atau dalam pengujian, membutuhkan waktu berbulan-bulan. Kami tidak dapat menghapus tes lama karena kami tidak tahu apa yang mereka uji!

Apa yang bisa kita lakukan Bagaimana cara melanjutkan tes legacy sebanyak itu?

Tinggalkan mereka.

Saya tahu sulit untuk melepaskan sesuatu yang jelas-jelas merupakan upaya yang banyak untuk dilakukan, tetapi tes tidak bekerja untuk Anda, mereka bekerja melawan Anda. Test suite seharusnya memberi Anda kepercayaan diri bahwa sistem melakukan apa yang seharusnya dilakukan. Jika tidak melakukannya, itu merupakan kewajiban alih-alih aset. Tidak masalah apakah sistem atau pengujian salah - selama menjalankan test suite menandakan sejumlah besar kesalahan, itu tidak dapat memenuhi tujuannya.

Yang Anda butuhkan sekarang adalah serangkaian tes baru yang berjalan tanpa kesalahan. Itu berarti pada awalnya akan memiliki sedikit cakupan, bahkan hampir tidak ada cakupan. Setiap kali Anda memperbaiki atau meluangkan waktu untuk benar-benar memahami sesuatu tentang sistem Anda, Anda memesan kembali pengetahuan itu dalam ujian. Seiring waktu, ini akan menghasilkan jaring pengaman baru yang dapat Anda bangun di masa depan. Mencoba menambal jaring pengaman yang lama dan tidak dipahami adalah waktu yang hampir tidak pernah berharga.

Saya bahkan akan menganjurkan agar tidak mentransfer tes dari suite lama ke suite baru. Tentu, beberapa dari mereka mungkin berhasil sekarang, tetapi apakah itu karena mereka menguji dengan tepat apa yang seharusnya mereka uji, atau hanya karena beberapa tembakan acak selalu mengenai target? Jelas Anda harus pragmatis tentang apa yang bisa dan tidak bisa dilakukan dengan upaya yang Anda miliki untuk dibelanjakan, tetapi Anda tidak bisa berkompromi pada prinsip bahwa test suite harus berjalan dengan bersih untuk melakukan tugasnya .

Pergi dan perbaiki tes.

Kesalahan terbesar Anda adalah bahwa Anda membiarkan tes gagal, dan Anda jelas mengabaikannya untuk sementara waktu. Apa yang Anda miliki bukan "tes warisan" - Anda sedang mengerjakan kode warisan. Dan saya menganggap setiap kode yang ditulis tanpa tes sebagai warisan.

Verifikasi kegagalan pengujian - jika masalah dalam produk atau dalam pengujian, membutuhkan waktu berbulan-bulan. Kami tidak dapat menghapus tes lama karena kami tidak tahu apa yang mereka uji!

Sepertinya ada masalah yang lebih besar di organisasi Anda, karena Anda tidak bekerja dengan persyaratan yang jelas. Saya tidak dapat mengerti bahwa Anda (atau orang lain) tidak dapat mengkonfirmasi perilaku yang benar.

Tes sangat berharga. Paling tidak, mereka mencatat bahwa seseorang menganggap bahwa mereka harus menghabiskan waktu menulisnya, sehingga mungkin mereka memiliki nilai bagi seseorang sekali. Dengan sedikit keberuntungan, mereka akan berisi catatan lengkap dari semua fitur dan bug yang pernah dikerjakan tim - meskipun mereka mungkin juga merupakan cara untuk mencapai beberapa angka cakupan uji arbitrer tanpa dipikirkan dengan cermat. Sampai Anda melihat mereka, Anda tidak akan tahu yang terjadi di sini.

Jika sebagian besar tes Anda melewati sebagian besar waktu, maka cukup gigit peluru dan investasikan waktu untuk mencari tahu apa yang beberapa tes gagal coba lakukan, dan apakah memperbaiki atau memperbaikinya sehingga pekerjaan akan lebih mudah di waktu berikutnya. Dalam hal ini, lewati untuk Menentukan maksud untuk setiap bagian tes , untuk beberapa saran tentang apa yang harus dilakukan dengan sejumlah kecil tes gagal.

Di sisi lain, Anda mungkin dihadapkan dengan bangunan Merah sekarang, dan ratusan atau bahkan ribuan tes yang belum berlalu untuk sementara waktu, dan Jenkins belum menjadi Hijau untuk waktu yang lama. Pada titik ini, status build Jenkins menjadi tidak berguna, dan indikator utama masalah dengan check-in Anda tidak lagi berfungsi. Anda harus memperbaiki ini, tetapi tidak mampu menghentikan semua kemajuan saat Anda merapikan kekacauan di ruang tamu Anda.

Untuk menjaga kewarasan Anda saat melakukan arkeologi yang diperlukan untuk menentukan nilai apa yang dapat dipulihkan dari tes yang gagal, saya akan merekomendasikan langkah-langkah berikut:

Nonaktifkan sementara tes yang gagal.

Ada beberapa cara Anda bisa melakukan ini, tergantung pada lingkungan Anda, yang tidak Anda jelaskan sehingga saya tidak bisa merekomendasikan yang mana pun.

Beberapa kerangka kerja mendukung gagasan kegagalan yang diharapkan. Jika Anda melakukannya, maka ini bagus, karena Anda akan melihat hitungan mundur berapa banyak tes yang tersisa dalam kategori ini, dan Anda bahkan akan diberi tahu jika beberapa dari mereka mulai lulus secara tak terduga.

Beberapa kerangka kerja mendukung kelompok uji, dan memungkinkan Anda memberi tahu Hudson hanya untuk menjalankan beberapa tes, atau untuk melewatkan sekelompok tes. Ini berarti Anda sesekali dapat menjalankan kelompok uji secara manual untuk melihat apakah ada yang lewat sekarang.

Beberapa kerangka kerja memungkinkan Anda untuk membubuhi keterangan atau menandai tes tunggal untuk Diabaikan. Lebih sulit untuk menjalankan mereka sebagai kelompok dalam kasus ini, tetapi menghentikan mereka dari mengganggu Anda.

Anda mungkin memindahkan tes ke pohon sumber yang biasanya tidak termasuk dalam build.

Dalam keadaan ekstrim, Anda dapat menghapus kode dari HEAD sistem kontrol versi, tetapi ini akan membuat lebih sulit untuk mengenali kapan fase ketiga telah selesai.

Tujuannya adalah membuat Jenkins menjadi ramah lingkungan sesegera mungkin, sehingga Anda bisa mulai bergerak ke arah yang benar sesegera mungkin.

Pertahankan tes yang relevan.

Putuskan untuk menambahkan tes baru saat Anda menambah atau memodifikasi kode, dan berkomitmen untuk menjaga semua lulus tes lulus.

Tes mungkin gagal karena berbagai alasan, termasuk fakta bahwa mereka bukan tes yang ditulis dengan baik untuk memulai. Tapi begitu Anda mendapatkan Jenkins hijau, mempertahankannya seperti itu sangat penting.

Biasakan menulis tes yang bagus, dan buat itu menjadi masalah besar jika tes mulai gagal.

Tentukan niat untuk setiap tes.

Pergi melalui tes yang dinonaktifkan satu per satu. Mulailah dengan modul yang memengaruhi modul yang paling sering Anda ubah. Tentukan niat tes, dan alasan kegagalan.

• Apakah ini menguji fitur yang dihapus dari basis kode dengan sengaja? Maka Anda mungkin dapat menghapusnya.

• Apakah itu menangkap bug yang belum diketahui oleh siapa pun? Pasang kembali tes dan perbaiki bug.

• Apakah gagal karena membuat asumsi yang tidak beralasan (mis. Asumsi teks tombol akan selalu dalam bahasa Inggris, tetapi sekarang Anda telah melokalkan aplikasi Anda untuk berbagai bahasa)? Kemudian cari tahu bagaimana membuat tes fokus pada satu hal, dan mengisolasinya dari perubahan yang tidak terkait sebaik mungkin.

• Apakah tes terkapar di seluruh aplikasi, dan mewakili tes Sistem? Kemudian hapus dari suite uji Jenkins utama Anda dan tambahkan ke suite Regresi yang lebih jarang berjalan.

• Apakah arsitektur aplikasi berubah tanpa bisa dikenali, sehingga tes tidak lagi berguna? Hapus.

• Apakah tes ditambahkan ke peningkatan statistik cakupan kode secara buatan, tetapi sebenarnya tidak lebih dari memastikan bahwa kode tersebut dikompilasi dengan benar dan tidak masuk ke loop tak terbatas? Atau yang lain, tes hanya mengkonfirmasi bahwa kerangka kerja mengejek yang Anda pilih mengembalikan hasil yang baru saja Anda katakan? Hapus.

Sebagai hasil dari ini, beberapa tes akan berdiri, beberapa dimodifikasi, beberapa dibagi menjadi beberapa potongan independen, ukuran gigitan, dan beberapa dihapus. Selama Anda masih membuat kemajuan dengan persyaratan baru, sisihkan sedikit waktu untuk berurusan dengan utang teknis seperti ini adalah hal yang bertanggung jawab untuk dilakukan.

4000 tes adalah masalah yang sulit diatasi. 40 tes lebih mudah ditelusuri. Pilih secara acak sejumlah tes yang dapat dikelola untuk dijalankan dan dianalisis. Klasifikasi hasil sebagai:

1. Tes tidak berguna
2. Tes berguna yang berjalan bersih
3. Tes berguna yang gagal

Jika banyak tes jatuh dalam kategori pertama, mungkin sudah saatnya untuk membuang suite tes Anda saat ini dan menyusun yang berguna untuk kode saat ini.

Jika banyak tes gagal dengan cara yang memberi tahu Anda tentang masalah dalam kode Anda, Anda perlu bekerja melalui tes gagal memperbaiki hal-hal. Anda mungkin menemukan bahwa memperbaiki satu atau dua bug membuat sejumlah besar tes berjalan.

Jika pernyataan ini benar,

Tes ... gagal seperti gila dengan setiap perubahan kode yang lebih besar.

maka itu menyiratkan bahwa jika Anda mengembalikan kode sebelum "perubahan kode lebih besar", maka banyak tes akan berlalu lagi. Setelah melakukan itu, ambil sebagian kecil perubahan dan lihat tes mana yang baru gagal. Ini akan membantu Anda mengisolasi perubahan kode yang menyebabkan tes gagal. Untuk setiap tes, setelah Anda mengisolasi masalahnya, Anda harus dapat menentukan apakah kode baru itu cacat, atau tes itu. Jika ada masalah dengan kode baru, pastikan untuk membandingkannya dengan versi terbaru kalau-kalau bug tertentu telah diperbaiki.

Ulangi sampai Anda memiliki basis kode terbaru.

Ini mungkin tampak seperti tugas yang berat, tetapi sangat mungkin bahwa sekali Anda melewati jalan ini dan mulai mengisolasi beberapa masalah, sebuah pola akan mulai muncul yang mungkin sangat mempercepat prosesnya. Sebagai contoh:

• Anda mungkin memperhatikan bahwa banyak tes tergantung pada hal lain yang cacat. Memperbaiki satu bagian itu dapat memperbaiki banyak tes.
• Anda mungkin memperhatikan bahwa banyak tes yang cacat dan perlu diperbaiki atau dihapus.
• Anda mungkin memperhatikan bahwa pengembang tertentu memiliki frekuensi yang jauh lebih tinggi untuk menyebabkan tes rusak. Pengembang itu mungkin membutuhkan lebih banyak pelatihan atau pengawasan.

Jika Anda tidak tahu apa yang mereka uji, hapus sampai Anda tahu. Pengujian adalah hal-hal yang lancar, jika Anda menghapus fitur yang tidak lagi diperlukan, maka Anda seharusnya harus mengubah tes yang menguji fitur itu! Jadi kecuali Anda tahu tes apa yang sedang diuji, Anda tidak memiliki harapan untuk mengubah basis kode dengan mereka di tempat.

Anda dapat mengatur sistem pengujian pada mesin pengembang dan menjalankannya di sana sehingga pengembang dapat melihat bagian mana dari tes yang berinteraksi, semoga memberikan dokumentasi yang hilang ini, dan menjadi lebih akrab dengan basis kode bahwa Anda tidak mengubah dengan benar, atau tidak pengujian lagi dengan benar.

Singkatnya - jika tes lama Anda gagal saat Anda membuat perubahan, perubahan kode Anda tidak baik. Gunakan tes-tes itu sebagai sarana pendidikan dalam cara kerja sistem.

Hal terpenting yang akan saya lakukan adalah kembali ke dasar-dasar pengujian apa yang seharusnya dilakukan, dan apa yang dibutuhkan bisnis untuk terus bergerak. Tugas pengujian adalah mengidentifikasi masalah sebelum menjadi mahal untuk diperbaiki nanti. Saya pikir kata kunci dalam kalimat itu adalah "mahal." Masalah-masalah ini membutuhkan solusi bisnis. Apakah masalah mahal muncul di lapangan? Jika demikian, pengujian gagal total.

Manajemen Anda dan Anda perlu melakukan pemeriksaan realitas. Anda menemukan bahwa biaya pengembangan meroket karena serangkaian tes warisan. Bagaimana perbandingan biaya tersebut dengan biaya pengiriman produk yang salah karena Anda menonaktifkan tes? Bagaimana mereka dibandingkan dengan tugas berat untuk benar-benar mengetahui perilaku apa yang dibutuhkan pengguna (hal-hal apa yang harus diuji)?

Ini adalah masalah yang memerlukan solusi bisnis karena menyentuh sisi bisnis dari pekerjaan. Anda mengirimkan produk ke pelanggan, dan itu adalah batas yang sangat diminati bisnis. Mereka mungkin dapat mengidentifikasi solusi yang tidak bisa Anda, sebagai pengembang, lakukan. Sebagai contoh, mungkin masuk akal bagi mereka untuk menyediakan dua produk: satu produk "warisan" bagi mereka yang membutuhkan keandalan dan bersedia untuk melupakan fitur-fitur baru, dengan satu produk "visioner" yang mungkin memiliki lebih banyak kesalahan, tetapi sedang merintis lebih dulu. Ini akan memberi Anda kesempatan untuk mengembangkan dua set tes independen ... satu legacy satu dengan 4000 tes, dan satu dengan lebih banyak tes yang menurut Anda perlu dilakukan (dan dokumentasikan agar proses ini tidak berulang).

Kemudian, seni dimulai: bagaimana Anda bisa mengelola binatang berkepala dua ini sehingga kemajuan di satu cabang juga membantu cabang lainnya? Bagaimana pembaruan Anda ke cabang "visonary" mengalir kembali ke cabang "legacy", meskipun persyaratan pengujiannya kaku. Bagaimana cara melanjutkan permintaan pelanggan pada cabang "legacy" dengan lebih baik membentuk pemahaman Anda tentang persyaratan yang akan dibutuhkan pelanggan lama Anda jika Anda akhirnya menggabungkan kembali produk-produk tersebut?

Kami tidak dapat menghapus tes lama karena kami tidak tahu apa yang mereka uji!

Itulah mengapa Anda harus menghapus tes lama! Jika Anda tidak tahu apa yang mereka lakukan, maka kegagalan tidak ada artinya dan menjalankannya adalah buang-buang waktu. Buang mereka dan mulai lagi.