Kami mulai mendorong cakupan kode di sini di tempat kerja saya, dan itu membuat saya berpikir .... Berapa banyak cakupan kode yang cukup?

Kapan Anda sampai pada titik berkurangnya pengembalian pada cakupan kode? Apa sweet spot antara liputan yang baik dan tidak cukup? Apakah ini bervariasi berdasarkan jenis proyek yang Anda buat (yaitu WPF, WCF, Mobile, ASP.NET) (Ini adalah kelas C # yang kami tulis.)

Kami menargetkan setidaknya 70%. Pada hal-hal yang lebih mudah diuji (struktur data fungsional, misalnya), kami bertujuan untuk 90% dan sebagian besar individu bertujuan untuk mendekati 100% mungkin. Pada hal-hal yang berhubungan dengan WPF dan kerangka kerja lain yang sangat sulit untuk diuji, kami mendapatkan cakupan yang jauh lebih rendah (hampir 70%).

Saya berpendapat bahwa cakupan kode saja adalah metrik yang buruk. Sangat mudah untuk menghasilkan banyak tes tidak berguna yang mencakup kode, tetapi tidak cukup memeriksa output, atau tidak menguji kasus tepi, misalnya. Menutupi kode hanya berarti tidak membuang pengecualian, bukankah itu benar. Anda memerlukan tes kualitas - kuantitasnya tidak terlalu penting.

"Cukup" adalah saat Anda dapat membuat perubahan pada kode Anda dengan keyakinan bahwa Anda tidak melanggar apa pun. Pada beberapa proyek, itu mungkin 10%, pada yang lain, mungkin 95%.

Ini hampir tidak pernah setinggi 100%. Namun, kadang-kadang mencoba untuk mendapatkan cakupan kode 100% bisa menjadi cara yang bagus untuk menghapus cruft dari basis kode. Jangan lupa bahwa ada dua cara untuk meningkatkan cakupan kode - tulis lebih banyak tes atau ambil kode. Jika kode tidak tercakup karena sulit untuk diuji, ada kemungkinan Anda dapat menyederhanakan atau refactor untuk membuatnya lebih mudah untuk diuji. Jika terlalu sulit untuk diuji, biasanya ada peluang baik bahwa tidak ada kode lain yang menggunakannya.

Cakupan kode mendekati 100% tanpa gejala. Akibatnya, 5% terakhir mungkin lebih banyak upaya daripada nilainya, karena Anda mulai mencapai pengembalian yang semakin kecil untuk upaya yang dikeluarkan.

Cakupan adalah sebuah metrik untuk mengawasi, tetapi tidak harus menjadi tujuan utama. Saya telah melihat (dan memang ditulis!) Banyak kode cakupan tinggi - cakupan 100% (TDD, tentu saja), namun:

• bug masih muncul
• desain masih buruk
• Anda dapat benar-benar bunuh diri menembak untuk beberapa target cakupan sewenang-wenang - pilih pertempuran Anda: hlm

Ada entri "The Way of Testivus" yang menurut saya pantas untuk referensi di sini :)

Hanya 20% dari sebagian besar kode akan berjalan 80% dari waktu . Analisis cakupan kode tidak terlalu berguna kecuali jika dipasangkan dengan grafik panggilan untuk menentukan apa yang paling perlu diuji. Itu memberitahu Anda di mana kasus tepi Anda berada. Anda dapat menghasilkan 100 tes hanya untuk kasus tepi tersebut, yang merupakan kurang dari 5% dari kode aktual.

Jadi, pastikan untuk mencakup 100% dari 20% yang mendefinisikan jalur kritis, dan setidaknya 50% sisanya (sesuai dengan grafik panggilan). Ini seharusnya membuat Anda (kira-kira) 70% - 75% cakupan total, tetapi bervariasi.

Jangan menghabiskan waktu mencoba untuk mendapatkan lebih dari 70% cakupan total sambil meninggalkan kasing tepi kritis tanpa cek.

Gunakan cakupan sebagai panduan untuk menunjukkan area yang tidak diuji. Daripada memiliki mandat untuk cakupan, lebih bijak untuk memahami alasan kode tidak tercakup. Mencatat alasan kekurangan adalah disiplin yang baik yang memungkinkan risiko untuk diseimbangkan.

Kadang-kadang alasannya kurang diinginkan 'misalnya kehabisan waktu' tetapi mungkin tidak apa-apa untuk rilis awal. Lebih baik menandai area untuk kembali ke untuk meningkatkan cakupan nanti.

Saya bekerja pada perangkat lunak penerbangan kritis di mana cakupan pernyataan 100% dianggap cocok untuk sistem yang tidak kritis. Untuk sistem yang lebih kritis kami memeriksa cakupan cabang / keputusan dan menggunakan teknik panggilan MC / DC yang kadang-kadang tidak cukup ketat.

Kami juga harus memastikan bahwa kami juga telah membahas kode objek.

Ini adalah keseimbangan antara risiko, dalam kasus kami sangat tinggi, terhadap nilai / biaya. Pilihan berdasarkan informasi dibutuhkan berdasarkan risiko hilangnya bug.

Ketika Anda mulai mempertimbangkan perubahan yang akan memengaruhi kinerja waktu berjalan, keamanan, fleksibilitas, atau pemeliharaan untuk memungkinkan lebih banyak cakupan kode, inilah saatnya untuk mengakhiri pencarian untuk lebih banyak cakupan kode.

Saya punya proyek di mana titik itu adalah 0% karena cakupan tidak mungkin dihitung tanpa merusak desain dan proyek lain di mana setinggi 92%.

Metrik cakupan kode hanya berguna untuk menunjukkan bahwa Anda mungkin telah melewatkan beberapa tes. Mereka tidak memberi tahu Anda tentang kualitas tes Anda.

Perangkat lunak ruang kritis membutuhkan cakupan pernyataan 100%.

Awalnya tidak masuk akal. Semua orang tahu bahwa cakupan pengujian penuh tidak berarti bahwa kode tersebut sepenuhnya diuji dan tidak sulit untuk mendapatkan cakupan 100% tanpa benar-benar menguji aplikasi.

Namun demikian, cakupan 100% adalah batas yang lebih rendah: walaupun cakupan 100% bukan merupakan bukti dari perangkat lunak bebas bug, dapat dipastikan bahwa dengan cakupan yang lebih rendah kode tersebut tidak sepenuhnya diuji dan ini hanya tidak dapat diterima untuk perangkat lunak ruang kritis.

Saya sangat suka jawaban @ RevBingo karena ia menyarankan bahwa perjuangan menuju 100% dapat menyebabkan Anda untuk membersihkan atau menghapus kode yang tidak digunakan. Apa yang belum saya lihat di jawaban lain adalah perasaan ketika Anda membutuhkan cakupan tinggi dan ketika Anda tidak. Saya mencoba memulai ini. Saya pikir menambahkan detail ke bagan seperti ini akan menjadi pengejaran yang lebih bermanfaat daripada menemukan satu nomor cakupan tes yang tepat untuk semua kode.

100%

Untuk API publik, seperti Koleksi java.util, yang tidak digabungkan ke Database dan tidak mengembalikan HTML, saya pikir cakupan 100% adalah tujuan awal yang mulia, bahkan jika Anda menerima 90-95% karena waktu atau lainnya kendala. Meningkatkan cakupan tes setelah Anda menampilkan kekuatan lengkap tingkat pengawasan yang lebih rinci daripada jenis review kode lainnya. Jika API Anda sama sekali populer, orang akan menggunakannya, mensubklasifikasikan, deserialize, dll. Dengan cara yang tidak dapat Anda harapkan. Anda tidak ingin pengalaman pertama mereka menemukan bug, atau pengawasan desain!

90%

Untuk kode infrastruktur bisnis, yang menggunakan struktur data dan mengembalikan struktur data, 100% mungkin masih merupakan tujuan awal yang baik, tetapi jika kode ini tidak cukup publik untuk mengundang banyak penyalahgunaan, mungkin 85% masih dapat diterima?

75%

Untuk kode yang menerima dan mengembalikan Strings, saya pikir pengujian unit jauh lebih rapuh, tetapi masih bisa berguna dalam banyak situasi.

50% atau kurang

Saya benci menulis tes untuk fungsi yang mengembalikan HTML karena sangat rapuh. Bagaimana jika seseorang mengubah CSS, JavaScript, atau seluruh gumpalan HTML dan bahasa Inggris yang Anda kembalikan tidak masuk akal bagi pengguna akhir manusia? Jika Anda dapat menemukan fungsi yang menggunakan banyak logika bisnis untuk menghasilkan sedikit HTML, ini mungkin layak untuk diuji. Tetapi situasi sebaliknya mungkin tidak layak untuk diuji sama sekali.

Mendekati 0%

Untuk beberapa kode, definisi "benar" adalah "masuk akal bagi pengguna akhir." Ada tes non-tradisional yang dapat Anda lakukan terhadap kode ini seperti pemeriksaan tata bahasa otomatis atau HTML memvalidasi output. Saya bahkan telah mengatur pernyataan grep untuk ketidakkonsistenan kecil yang biasanya kita menjadi mangsa di tempat kerja, seperti mengatakan "Login" ketika seluruh sistem menyebutnya, "Masuk". Pria ini tidak sepenuhnya menjadi unit test, tetapi cara yang bermanfaat untuk menangkap masalah tanpa mengharapkan output spesifik.

Namun pada akhirnya, hanya manusia yang bisa menilai apa yang masuk akal bagi manusia. Pengujian unit tidak dapat membantu Anda di sana. Terkadang dibutuhkan beberapa manusia untuk menilai itu dengan akurat.

Absolut 0%

Ini adalah kategori yang menyedihkan dan saya merasa kurang dari orang untuk menulisnya. Tetapi dalam proyek yang cukup besar ada lubang kelinci yang dapat menyedot waktu orang-minggu tanpa memberikan manfaat bisnis.

Saya membeli buku karena diklaim menunjukkan cara mengolok-olok data untuk menguji Hibernate. Tapi itu hanya menguji Hibernate HQL dan SQL queries. Jika Anda harus melakukan banyak HQL dan SQL, Anda benar-benar tidak mendapatkan keuntungan dari Hibernate. Ada bentuk database Hibernate di memori, tapi saya belum menginvestasikan waktu untuk mencari tahu bagaimana menggunakannya secara efektif dalam tes. Jika saya menjalankannya, saya ingin memiliki cakupan pengujian yang tinggi (50% -100%) untuk logika bisnis apa pun yang menghitung barang dengan menavigasi grafik objek yang menyebabkan Hibernate menjalankan beberapa permintaan. Kemampuan saya untuk menguji kode ini mendekati 0% sekarang dan itu masalah. Jadi saya meningkatkan cakupan pengujian di area lain dari proyek dan mencoba untuk lebih memilih fungsi murni daripada yang mengakses database, terutama karena lebih mudah untuk menulis tes untuk fungsi-fungsi tersebut. Masih,

Saya pikir itu tergantung pada bagian aplikasi yang Anda uji. Misalnya untuk logika bisnis atau komponen apa pun yang melibatkan transformasi data yang kompleks, saya akan menargetkan cakupan 90% (setinggi mungkin). Saya sering menemukan bug kecil tapi berbahaya dengan hanya menguji sebanyak mungkin kode. Saya lebih suka menemukan bug seperti itu selama pengujian daripada membiarkannya terjadi di situs pelanggan satu tahun kemudian. Juga, manfaat dari cakupan kode yang tinggi adalah mencegah orang dari mengubah kode kerja terlalu mudah, karena tes harus disesuaikan.

Di sisi lain, saya pikir ada komponen yang cakupan kode kurang cocok. Misalnya, ketika menguji GUI, sangat memakan waktu untuk menulis tes yang mencakup semua kode yang dieksekusi ketika mengklik tombol untuk mengirimkan acara ke komponen yang tepat. Saya pikir dalam kasus ini jauh lebih efektif untuk menggunakan pendekatan tradisional melakukan tes manual di mana Anda cukup mengklik tombol dan mengamati perilaku program (apakah jendela dialog kanan terbuka? Apakah alat yang tepat bisa dipilih? ?).

Saya tidak memiliki pendapat yang tinggi tentang penggunaan cakupan kode sebagai ukuran untuk mengetahui kapan test suite Anda memiliki cakupan yang cukup.

Alasan utama mengapa adalah karena jika Anda memiliki proses di mana Anda pertama kali menulis beberapa kode, kemudian beberapa tes, dan kemudian melihat cakupan kode untuk menemukan di mana Anda telah melewatkan tes, maka itu adalah Anda proses yang perlu ditingkatkan. Jika Anda melakukan TDD yang benar, maka Anda memiliki cakupan kode 100% di luar kotak (harus diakui, ada beberapa hal sepele yang tidak saya uji). Tetapi jika Anda melihat cakupan kode untuk mencari tahu apa yang harus diuji, maka Anda kemungkinan akan menulis tes yang salah.

Jadi, satu-satunya hal yang dapat Anda simpulkan dari cakupan kode adalah jika terlalu rendah, Anda tidak memiliki cukup tes. Tetapi jika tinggi, tidak ada jaminan bahwa Anda memiliki semua tes yang tepat.