Haruskah kita mengecualikan kode untuk analisis cakupan kode?

Saya sedang mengerjakan beberapa aplikasi, terutama yang lama. Saat ini, cakupan kode mereka cukup rendah: umumnya antara 10 dan 50%.

Sejak beberapa minggu, kami memiliki diskusi berulang dengan tim Bangalore (bagian utama dari pengembangan dilakukan di lepas pantai di India) mengenai pengecualian paket atau kelas untuk Cobertura (alat cakupan kode kami, bahkan jika kami saat ini sedang bermigrasi ke JaCoCo).

Sudut pandang mereka adalah sebagai berikut: karena mereka tidak akan menulis unit test pada beberapa layer aplikasi (1) , layer-layer ini harus dikeluarkan dari ukuran cakupan kode. Dengan kata lain, mereka ingin membatasi ukuran cakupan kode untuk kode yang diuji atau harus diuji .

Juga, ketika mereka bekerja pada unit test untuk kelas yang kompleks, manfaat - murni dalam hal cakupan kode - akan diperhatikan karena dalam aplikasi besar. Mengurangi ruang lingkup cakupan kode akan membuat upaya semacam ini lebih terlihat ...

Yang menarik dari pendekatan ini adalah bahwa kita akan memiliki ukuran cakupan kode yang menunjukkan status saat ini dari bagian aplikasi yang kita anggap dapat diuji .

Namun, sudut pandang saya adalah bahwa kita entah bagaimana berpura-pura angka. Solusi ini adalah cara mudah untuk mencapai tingkat cakupan kode yang lebih tinggi tanpa upaya apa pun. Poin lain yang mengganggu saya adalah sebagai berikut: jika kami menunjukkan peningkatan cakupan dari satu minggu ke minggu lainnya, bagaimana kami dapat mengetahui apakah kabar baik ini disebabkan oleh kerja yang baik dari para pengembang, atau hanya karena pengecualian baru?

Selain itu, kami tidak akan dapat mengetahui dengan tepat apa yang dipertimbangkan dalam ukuran cakupan kode. Misalnya, jika saya memiliki 10.000 baris aplikasi kode dengan 40% cakupan kode, saya dapat mengurangi bahwa 40% dari basis kode saya diuji (2) . Tetapi apa yang terjadi jika kita menetapkan pengecualian? Jika cakupan kode sekarang 60%, apa yang bisa saya kurangi dengan tepat? Bahwa 60% basis kode "penting" saya diuji? Bagaimana bisa saya

Sejauh yang saya ketahui, saya lebih suka menyimpan nilai cakupan kode "nyata", bahkan jika kita tidak bisa ceria tentang hal itu. Selain itu, terima kasih kepada Sonar, kami dapat dengan mudah menavigasi dalam basis kode kami dan mengetahui, untuk setiap modul / paket / kelas, cakupan kodenya sendiri. Namun tentu saja, cakupan kode global akan tetap rendah.

Apa pendapat Anda tentang hal itu? Bagaimana yang Anda lakukan pada proyek Anda?

Terima kasih.

(1) Lapisan ini umumnya terkait dengan UI / Java beans, dll.

(2) Saya tahu itu tidak benar. Bahkan, itu hanya berarti bahwa 40% dari basis kode saya

Saya biasanya mengecualikan kode yang dibuat secara otomatis, seperti klien WCF yang dihasilkan oleh Visual Studio. Biasanya ada banyak baris kode di sana dan kami tidak akan pernah mengujinya. Ini membuatnya sangat melemahkan untuk meningkatkan pengujian pada sejumlah besar kode di tempat lain dan hanya meningkatkan cakupan kode sebesar 0,1%.

Saya juga akan mengecualikan interaksi lapisan data, selama tim dapat mengatakan dengan pasti bahwa lapisan ini setipis mungkin. Meskipun Anda dapat berargumen bahwa, jika lapisannya tipis, itu tidak akan memiliki efek besar, ia meninggalkan banyak komponen dalam laporan cakupan dengan 0% terhadap mereka, jadi kami tidak selalu memperhatikan yang kita butuhkan untuk benar-benar khawatir. Lapisan UI dapat diperdebatkan dengan cara yang sama, tergantung pada kerangka yang digunakan.

Tapi, sebagai titik balik, saya juga akan mengecualikan unit test sendiri. Mereka harus selalu memiliki ~ cakupan 100% dan mereka berjumlah persentase besar basis kode, angka miring cenderung berbahaya.

Pertanyaan bagus. Secara umum saya cenderung mengecualikan kode dari cakupan kode karena beberapa alasan, misalnya:

• dihasilkan
• legacy (tidak diperbarui lagi)
• ini dia: lapisan tertentu, saya tidak bermaksud untuk menguji

Mengapa poin terakhir? Saya pikir itu praktik yang baik untuk fokus pada hal-hal yang saya pedulikan, sambil menekan gangguan. Jika Anda tidak bermaksud untuk menguji UI-Layer, mengapa mempertimbangkannya - itu hanya akan menarik perhatian dari bagian penting dari perangkat lunak Anda - logika bisnis.

TAPI:

1. Anda harus memiliki alasan yang bagus, mengapa mengecualikan lapisan tertentu dari pengujian unit sama sekali (mungkin ada pertanyaan - dari bos Anda, rekan tim Anda, pers ;-)
2. Jika Anda ingin mereka menguji lapisan ini, Anda harus memasukkannya dalam statistik untuk menunjukkan kepada seluruh tim, setiap hari itu penting dan perlu dilakukan.

Akhirnya: jangan menganggap angka terlalu serius. Cakupan 30% dapat membuktikan solid perangkat lunak, ketika itu adalah bagian penting dari itu.

Saya cenderung setuju dengan Anda, dan memasukkan semua kode yang relevan dalam metrik cakupan kode (dan Sonar secara umum). Bahkan jika Anda tidak berencana untuk menguji beberapa bagian kode (untuk masa yang akan datang), metrik harus mencerminkan status aktual. Ini memaksa Anda untuk memiliki alasan kuat untuk tidak menulis tes untuk sebagian besar basis kode. Akhirnya (sekali lagi, bagian yang lebih penting dari kode sudah dibahas) Anda dapat mempertimbangkan kembali, atau memilih cara lain untuk menghilangkan disonansi ini - misalnya dengan refactoring kode yang bersangkutan untuk membuatnya dapat diuji, atau untuk memigrasi semua logika dari itu ke dalam berbeda, bagian yang dapat diuji dari basis kode, atau bahkan untuk menghilangkan seluruh lapisan secara keseluruhan (jika suatu lapisan tidak layak untuk diuji, apakah ia memiliki alasan yang cukup bagus untuk ada?)

Dalam proyek saya saat ini, kami juga memasukkan semua kode dalam metrik, dengan satu pengecualian: kode yang dihasilkan, menghasilkan banyak peringatan analisis statis. Karena kode ini biasanya terdiri dari kelas POD humongous tanpa logika apa pun, tidak ada yang bisa diuji di sana.

Sekarang saya tidak banyak mengenal alat-alat cakupan kode yang Anda gunakan atau saya tidak akrab dengan kacang Jawa, tetapi dari apa yang Anda katakan mereka terkait dengan UI.

Dengan pengetahuan saya yang terbatas, saya ingin mengatakan ini:

1. Jangan biarkan angka dengan alat pengujian apa pun menghalangi tes Anda.
2. Jika kelas-kelas itu kompleks dan tidak dapat diuji unit, selalu merupakan ide yang baik untuk memfaktorkan ulang mereka ke dalam kelas yang lebih kompak dan dapat diuji. Ini akan membutuhkan banyak upaya dan dedikasi, tetapi itu akan membayar dalam jangka panjang.
3. Menguji komponen UI bisa jadi sulit, tetapi Anda masih bisa menguji fungsi yang sedang dilakukan oleh komponen-komponen itu.
4. Jika Anda melakukan proyek berbasis web maka Anda dapat menggunakan QUnit untuk menguji semua kode sisi klien.

Secara keseluruhan, Anda harus ingat bahwa cakupan kode hanyalah angka, dan cakupan kode tinggi tidak menunjukkan tes yang baik. Fokus pada membuat perpustakaan inti lebih kuat dan teruji daripada bertujuan untuk persentase yang lebih tinggi.

Beberapa pengecualian masuk akal (kode pelat boiler yang tidak memiliki dampak nyata atau potensi dampak pada proyek Anda berfungsi dengan benar). Bahkan masih mengumpulkan cakupan kode sebagai metrik tidak ada gunanya karena tidak memberi tahu Anda apa pun yang berguna. Cakupan kode 100% bukan tujuan nyata, dan angka cakupan rendah juga mungkin tidak buruk tergantung pada proyek, mungkin saja cakupan kode 20-30% mencakup semua yang layak untuk diuji. cakupan kode hanya memberi tahu Anda X% dari kode Anda yang berpotensi untuk dicakup sebenarnya oleh beberapa jenis pengujian dengan kualitas yang tidak diketahui.

Saya sarankan melaporkan sekumpulan metrik untuk setiap lapisan kode Anda. Metrik ini harus mencakup informasi ukuran (misalnya, LoC, jumlah perpustakaan, jumlah kelas atau metode, dll.), Informasi pengujian (misalnya, cakupan), dan informasi bug (mis., Temukan dan perbaiki tarif).

Lapisan Anda yang dikecualikan akan memiliki cakupan 0%, dan area yang diuji akan memiliki cakupan 60% yang Anda sebutkan. Informasi ukuran akan membuat orang mengerti berapa banyak yang belum diuji atau diuji. Informasi bug akan memberi tahu Anda jika Anda mungkin harus membuat tes untuk lapisan yang dikecualikan, dan jika tes yang ada berfungsi.

Mudah bagi organisasi perangkat lunak untuk menjadi terlalu fokus pada kemurnian metrik. Kami tidak membuat metrik, kami membuat perangkat lunak yang baik. Metrik yang membantu Anda menghadirkan perangkat lunak berkualitas tinggi tepat waktu adalah metrik paling jujur ​​dan murni.