Setiap alat / saran tentang cara menyangkal argumen kualitas cakupan kode

Sekarang saya tahu orang-orang dapat mempertimbangkan pertanyaan ini duplikat atau ditanyakan berkali-kali, dalam hal ini saya akan menghargai tautan ke pertanyaan yang relevan dengan jawaban atas pertanyaan saya.

Saya baru-baru ini berselisih dengan beberapa orang tentang cakupan kode. Saya memiliki sekelompok orang yang ingin tim kami berhenti melihat cakupan kode secara keseluruhan berdasarkan argumen bahwa cakupan 100% tidak berarti tes kualitas yang baik dan dengan demikian kode kualitas yang baik.

Saya dapat mendorong kembali dengan menjual argumen yang Kode Cakupan memberi tahu saya apa yang belum diuji pasti dan membantu kami fokus pada bidang-bidang tersebut.

(Hal di atas telah dibahas dengan cara yang sama dalam pertanyaan SO lainnya seperti ini - /programming/695811/pitfalls-of-code-coverage )

Argumen dari orang-orang ini adalah - maka tim akan bereaksi dengan cepat membuat tes berkualitas rendah dan dengan demikian membuang waktu sambil menambahkan tidak ada kualitas yang signifikan.

Sementara saya memahami sudut pandang mereka, saya mencari cara untuk membuat kasus yang lebih kuat untuk cakupan kode dengan memperkenalkan alat / kerangka kerja yang lebih kuat yang menangani lebih banyak kriteria cakupan (Functional, Statement,Decision, Branch, Condition, State, LCSAJ, path, jump path, entry/exit, Loop, Parameter Value etc) .

Apa yang saya cari adalah saran untuk kombinasi alat cakupan kode dan praktik / proses untuk pergi dengan mereka yang dapat membantu saya melawan argumen tersebut sambil merasa nyaman dengan rekomendasi saya.

Saya juga akan menyambut komentar / saran yang menyertainya berdasarkan pengalaman / pengetahuan Anda tentang cara untuk melawan argumen seperti itu, karena meskipun subjektif, cakupan kode telah membantu tim saya menjadi lebih sadar akan kualitas kode dan nilai pengujian.

Sunting: Untuk mengurangi kebingungan tentang pemahaman saya tentang kelemahan cakupan kode tipikal, saya ingin menunjukkan bahwa saya tidak merujuk pada alat Statement Coverage (atau baris kode yang dijalankan) (ada banyak). Sebenarnya di sini ada artikel bagus tentang segala sesuatu yang salah dengan itu: http://www.bullseye.com/statementCoverage.html

Saya mencari lebih dari sekedar pernyataan atau cakupan garis, lebih ke beberapa kriteria dan tingkat cakupan.

Lihat: http://en.wikipedia.org/wiki/Code_coverage#Coverage_criteria

Idenya adalah jika alat dapat memberi tahu kami cakupan kami berdasarkan beberapa kriteria, maka itu menjadi penilaian otomatis kualitas tes yang wajar. Saya sama sekali tidak berusaha mengatakan bahwa cakupan garis adalah penilaian yang baik. Sebenarnya itu adalah premis dari pertanyaan saya.

Sunting:
Ok, mungkin saya memproyeksikannya agak terlalu dramatis, tetapi Anda mengerti maksudnya. Masalahnya adalah tentang menetapkan proses / kebijakan secara umum di semua tim dengan cara yang homogen / konsisten. Dan rasa takutnya adalah umum bahwa bagaimana Anda memastikan kualitas tes, bagaimana Anda mengalokasikan waktu yang dijamin tanpa harus mengukurnya. Jadi saya suka memiliki fitur yang terukur bahwa ketika didukung dengan proses yang tepat dan alat yang tepat akan memungkinkan kami untuk meningkatkan kualitas kode sambil mengetahui bahwa waktu tidak dihabiskan dengan paksa dalam proses yang boros.

EDIT: Sejauh ini apa yang saya dapatkan dari jawaban:

• Ulasan kode harus mencakup tes untuk memastikan kualitas tes
• Strategi Tes Pertama membantu menghindari tes yang ditulis setelah fakta untuk hanya meningkatkan cakupan%
• Menjelajahi alat-alat alternatif yang mencakup kriteria pengujian selain sekadar Pernyataan / Baris
• Analisis kode tertutup / jumlah bug yang ditemukan akan membantu menghargai pentingnya perlindungan dan membuat kasus yang lebih baik
• Yang terpenting, percaya masukan Tim untuk melakukan hal yang benar dan memperjuangkan keyakinan mereka
• Blok Tertutup / # tes - Debatable tetapi memiliki beberapa nilai

Terima kasih atas jawaban yang luar biasa sejauh ini. Saya sangat menghargai mereka. Utas ini lebih baik daripada berjam-jam bertukar pikiran dengan kekuatan yang ada.

Dalam pengalaman saya, cakupan kode sama berguna dengan Anda membuatnya . Jika Anda menulis tes yang bagus yang mencakup semua kasus Anda, maka lulus tes itu berarti Anda telah memenuhi persyaratan Anda. Bahkan itulah ide yang tepat yang menggunakan Test Driven Development . Anda menulis tes sebelum kode tanpa mengetahui apa pun tentang implementasi (Terkadang ini berarti tim lain sepenuhnya menulis tes). Tes-tes ini diatur untuk memverifikasi bahwa produk akhir melakukan semua yang menurut spesifikasi Anda telah dilakukan, dan KEMUDIAN Anda menulis kode minimum untuk lulus tes-tes tersebut.

Masalahnya di sini, jelas, adalah bahwa jika tes Anda tidak cukup kuat, Anda akan kehilangan kasus tepi atau masalah yang tak terduga dan menulis kode yang tidak benar-benar memenuhi spesifikasi Anda. Jika Anda benar-benar mulai menggunakan tes untuk memverifikasi kode Anda, maka menulis tes yang baik adalah kebutuhan mutlak, atau Anda benar-benar membuang-buang waktu.

Saya ingin mengedit jawaban di sini karena saya menyadari bahwa itu tidak benar-benar menjawab pertanyaan Anda. Saya akan melihat artikel wiki itu untuk melihat beberapa manfaat TDD yang dinyatakan. Ini benar-benar bermuara pada bagaimana organisasi Anda bekerja paling baik, tetapi TDD jelas merupakan sesuatu yang digunakan dalam industri.

Pertama, orang melakukan advokasi cakupan 100%:

Sebagian besar pengembang melihat ... "cakupan pernyataan 100%" memadai. Ini adalah awal yang baik, tetapi hampir tidak cukup. Id standar cakupan yang lebih baik untuk memenuhi apa yang disebut "cakupan cabang 100%," ...

Steve McConnell, Kode Lengkap , Bab 22: Pengujian Pengembang.

Seperti yang Anda dan orang lain sebutkan, cakupan kode hanya demi cakupan saja tidak akan menghasilkan banyak hal. Tetapi jika Anda tidak dapat membuat baris kode dieksekusi, mengapa ini ditulis?

Saya sarankan menyelesaikan argumen dengan mengumpulkan dan menganalisis data pada proyek Anda sendiri.

Untuk mengumpulkan data, saya pribadi menggunakan alat berikut:

• JaCoCo dan plugin Eclipse EclEmma terkait untuk mengukur cakupan kode.
• Skrip semut untuk bangunan otomatis, pengujian, dan pelaporan.
• Jenkins untuk pembangunan berkelanjutan - setiap perubahan dalam kontrol sumber memicu pembangunan otomatis
• Plugin JaCoCo untuk Jenkins - menangkap metrik cakupan untuk setiap bangunan, dan membuat grafik tren. Juga memungkinkan definisi ambang batas cakupan per proyek yang mempengaruhi kesehatan bangunan.
• Bugzilla untuk melacak bug.

Setelah Anda memiliki (atau yang serupa) di tempat, Anda dapat mulai melihat data Anda sendiri lebih dekat:

• ada bug lebih banyak ditemukan di proyek-proyek yang tidak tercakup?
• Apakah lebih banyak bug ditemukan di kelas / metode yang tidak tercakup?
• dll.

Saya berharap bahwa data Anda akan mendukung posisi Anda dalam cakupan kode; itu tentu saja pengalaman saya. Namun, jika tidak, maka organisasi Anda dapat berhasil dengan standar cakupan kode yang lebih rendah daripada yang Anda inginkan. Atau mungkin tes Anda tidak terlalu baik. Tugas ini diharapkan akan memfokuskan upaya memproduksi perangkat lunak dengan cacat yang lebih sedikit, terlepas dari resolusi pertentangan cakupan kode.

Argumen dari orang-orang ini adalah - tim akan bereaksi dengan cepat membuat tes kualitas rendah dan dengan demikian membuang waktu sambil menambahkan kualitas yang tidak signifikan.

Ini adalah masalah kepercayaan , bukan alat .

Tanyakan kepada mereka mengapa, jika mereka benar-benar percaya pernyataan itu, mereka akan mempercayai tim untuk menulis kode apa pun?

Ok, mungkin saya memproyeksikannya agak terlalu dramatis, tetapi Anda mengerti maksudnya. Masalahnya adalah tentang menetapkan proses / kebijakan secara umum di semua tim dengan cara yang homogen / konsisten.

Saya pikir itu masalahnya. Pengembang tidak peduli (dan seringkali karena alasan yang sangat baik) tentang kebijakan yang konsisten atau global, dan menginginkan kebebasan untuk melakukan apa yang menurut mereka benar daripada mematuhi kebijakan perusahaan.

Yang masuk akal kecuali Anda membuktikan bahwa proses dan tindakan global memiliki nilai dan efek positif pada kualitas dan kecepatan pembangunan.

Timeline biasa:

1. dev: hei, lihat - saya menambahkan metrik cakupan kode ke dasbor kami, bukankah itu hebat?
2. manajer: tentu, mari tambahkan tujuan wajib dan kepatuhan pada mereka
3. dev: sudahlah, cakupan kode itu bodoh dan tidak berguna, ayo drop it

Dalam pengalaman saya, ada beberapa hal untuk digabungkan dengan cakupan kode untuk membuat metrik berharga:

Ulasan Kode

Jika Anda dapat menarik kembali tes buruk ke pengembang, ini dapat membantu membatasi jumlah tes buruk yang menyediakan cakupan yang tidak berarti ini.

Pelacakan Bug

Jika Anda memiliki banyak cakupan kode pada modul, tetapi masih mendapatkan banyak / bug yang parah di daerah itu, maka itu mungkin menunjukkan masalah di mana pengembang perlu perbaikan dengan tes mereka.

Pragmatisme

Tidak ada yang akan mendapatkan 100% dengan tes yang baik pada kode non-sepele. Jika Anda sebagai pemimpin tim melihat cakupan kode, tetapi alih-alih mengatakan "kita harus mencapai N%!" Anda mengidentifikasi kesenjangan dan meminta orang untuk "meningkatkan cakupan dalam modul X" yang mencapai tujuan Anda tanpa memberi orang kesempatan untuk memainkan sistem.

Blok yang Dicakup / # Tes

Sebagian besar alat kode cakupan mencantumkan blok yang dicakup vs yang tidak dicakup. Menggabungkan ini dengan sejumlah tes aktual memungkinkan Anda mendapatkan metrik yang menunjukkan seberapa 'luasnya' tes, baik yang mengindikasikan tes buruk atau desain yang digabungkan. Ini lebih berguna sebagai delta dari satu sprint ke sprint yang lain, tetapi idenya sama - gabungkan cakupan kode dengan metrik lain untuk mendapatkan lebih banyak wawasan.

Ini 2 sen saya.

Ada banyak praktik yang telah menerima banyak perhatian baru-baru ini karena dapat membawa manfaat bagi pengembangan perangkat lunak. Namun, beberapa pengembang menerapkan praktik-praktik itu secara membabi buta: mereka yakin bahwa menerapkan suatu metodologi seperti mengeksekusi algoritma dan bahwa setelah melakukan langkah-langkah yang benar seseorang harus mendapatkan hasil yang diinginkan.

Beberapa contoh:

• Tulis tes unit dengan cakupan kode 100% dan Anda akan mendapatkan kualitas kode yang lebih baik.
• Terapkan TDD secara sistematis dan Anda akan mendapatkan desain yang lebih baik.
• Lakukan pair programming dan Anda akan meningkatkan kualitas kode dan mengurangi waktu pengembangan.

Saya pikir masalah dasar dengan pernyataan di atas adalah bahwa manusia bukan komputer dan menulis perangkat lunak tidak seperti mengeksekusi algoritma.

Jadi, pernyataan di atas mengandung beberapa kebenaran tetapi terlalu menyederhanakan banyak hal, misalnya:

• Tes unit menangkap banyak kesalahan dan cakupan kode menunjukkan bagian mana dari kode yang diuji, tetapi pengujian hal-hal sepele tidak berguna. Misalnya, jika dengan mengklik tombol dialog yang sesuai terbuka, seluruh logika mengirim acara tombol ke komponen yang membuka dialog dapat diuji dengan tes manual sederhana (klik pada tombol): apakah itu membayar ke unit menguji logika ini?
• Meskipun TDD adalah alat desain yang bagus, TDD tidak berfungsi dengan baik jika pengembang memiliki pemahaman yang buruk tentang domain masalah (lihat misalnya pos terkenal ini ).
• Pemrograman pasangan efektif jika dua pengembang dapat bekerja bersama, jika tidak itu adalah bencana. Juga, pengembang yang berpengalaman mungkin lebih suka membahas secara singkat masalah yang paling penting dan kemudian membuat kode secara terpisah: menghabiskan banyak waktu membahas banyak detail yang mereka berdua tahu bisa membosankan dan menghabiskan banyak waktu.

Kembali ke cakupan kode.

Saya dapat mendorong kembali dengan menjual argumen yang Kode Cakupan memberi tahu saya apa yang belum diuji pasti dan membantu kami fokus pada bidang-bidang tersebut.

Saya pikir Anda harus menilai dari kasus ke kasus jika perlu memiliki cakupan 100% untuk modul tertentu.

Apakah modul melakukan beberapa perhitungan yang sangat penting dan rumit? Kemudian saya ingin menguji setiap baris kode tetapi juga menulis tes unit yang bermakna (tes unit yang masuk akal dalam domain itu).

Apakah modul melakukan beberapa tugas penting namun sederhana seperti membuka jendela bantuan saat mengklik tombol? Tes manual mungkin akan lebih efektif.

Argumen dari orang-orang ini adalah - maka tim akan bereaksi dengan cepat membuat tes berkualitas rendah dan dengan demikian membuang waktu sambil menambahkan tidak ada kualitas yang signifikan.

Menurut pendapat saya mereka benar: Anda tidak dapat menegakkan kualitas kode dengan hanya membutuhkan cakupan kode 100%. Menambahkan lebih banyak alat untuk menghitung cakupan dan membuat statistik juga tidak akan membantu. Sebaliknya, Anda harus mendiskusikan bagian mana dari kode yang lebih sensitif dan harus diuji secara luas dan mana yang kurang rawan kesalahan (dalam arti bahwa kesalahan dapat ditemukan dan diperbaiki lebih mudah tanpa menggunakan unit test).

Jika Anda mendorong cakupan kode 100% ke pengembang, beberapa akan mulai menulis tes unit konyol untuk memenuhi kewajiban mereka alih-alih mencoba menulis tes masuk akal.

bagaimana Anda mengalokasikan waktu yang dijamin tanpa mengukurnya

Mungkin ilusi bahwa Anda bisa mengukur kecerdasan dan penilaian manusia. Jika Anda memiliki kolega yang kompeten dan Anda memercayai penilaian mereka, Anda dapat menerima ketika mereka memberi tahu Anda "untuk modul ini, meningkatkan cakupan kode akan membawa manfaat yang sangat kecil. Jadi jangan menghabiskan waktu di atasnya" atau, "untuk modul ini kita perlu sebanyak cakupan yang kita dapat, kita perlu satu minggu ekstra untuk menerapkan tes unit yang masuk akal. "

Jadi (sekali lagi, ini adalah 2 sen saya): jangan mencoba untuk menemukan proses dan mengatur parameter seperti cakupan kode yang harus sesuai dengan semua tim, untuk semua proyek dan untuk semua modul. Menemukan proses umum semacam itu adalah ilusi dan saya percaya bahwa ketika Anda menemukannya, itu akan menjadi kurang optimal.

"Tim akan bereaksi dengan dengan cepat membuat tes kualitas rendah dan dengan demikian membuang waktu sambil menambahkan tidak ada kualitas yang signifikan"

Ini risiko nyata, bukan hanya teoretis.

Terlalu banyak kode saja adalah metrik disfungsional. Saya belajar pelajaran itu dengan cara yang sulit. Suatu kali, saya menekankannya tanpa ketersediaan metrik atau praktik penyeimbang. Ratusan tes yang menangkap dan menutupi pengecualian, dan tanpa penegasan adalah hal yang jelek.

"saran untuk kombinasi alat cakupan praktik dan proses / proses seperti itu untuk pergi bersama mereka"

Selain semua saran lain, ada satu teknik otomatisasi yang dapat menilai kualitas tes: pengujian mutasi ( http://en.wikipedia.org/wiki/Mutation_testing ). Untuk kode Java, PIT ( http://pitest.org/ ) berfungsi, dan ini adalah alat pengujian mutasi pertama yang saya temui.

Seperti yang Anda perhatikan, kurangnya cakupan kode mudah diidentifikasi sebagai risiko kualitas perangkat lunak. Saya mengajarkan bahwa cakupan kode adalah syarat yang diperlukan, tetapi tidak memadai, untuk kualitas perangkat lunak. Kami harus mengambil pendekatan balanced scorecard untuk mengelola kualitas perangkat lunak.

Cakupan kode tentu bukan bukti pengujian unit yang baik, karena benar.

Tetapi kecuali mereka dapat memberikan cara untuk membuktikan bahwa semua tes unit baik (untuk definisi apa pun yang baik yang dapat mereka buat) maka ini benar-benar titik bisu.

Saya selalu menemukan bahwa cakupan kode mudah rentan terhadap Efek Hawthorne . Ini membuat saya bertanya "mengapa kita memiliki metrik perangkat lunak sama sekali?" dan jawabannya biasanya adalah untuk memberikan pemahaman tingkat tinggi tentang keadaan proyek saat ini, hal-hal seperti:

"seberapa dekat kita dengan kita?"

"Bagaimana kualitas sistem ini?"

"betapa rumitnya modul-modul ini?"

Sayangnya, tidak akan pernah ada metrik tunggal yang dapat memberi tahu Anda seberapa baik atau buruk proyek ini, dan segala upaya untuk memperoleh makna dari satu angka akan terlalu menyederhanakan. Walaupun metrik adalah tentang data, menafsirkan artinya adalah tugas yang jauh lebih emosional / psikologis dan karena itu mungkin tidak dapat diterapkan secara umum di seluruh tim dengan komposisi atau masalah yang berbeda dari domain yang berbeda.

Dalam hal cakupan saya pikir itu sering digunakan sebagai proksi untuk kualitas kode, albiet yang mentah. Dan masalah sebenarnya adalah bahwa ia menurunkan topik yang sangat rumit menjadi satu bilangan bulat antara 0 dan 100 yang tentu saja akan digunakan untuk mendorong pekerjaan yang berpotensi tidak membantu dalam pencarian tanpa akhir untuk mencapai cakupan 100%. Orang-orang seperti Bob Martin akan mengatakan bahwa cakupan 100% adalah satu-satunya tujuan serius, dan saya dapat mengerti mengapa demikian, karena hal lain sepertinya sewenang-wenang.

Tentu saja ada banyak cara untuk mendapatkan cakupan yang sebenarnya tidak membantu saya mendapatkan pemahaman tentang basis kode - mis. Apakah berharga untuk menguji toString ()? bagaimana dengan getter dan setter untuk objek yang tidak bisa diubah? Sebuah tim hanya memiliki begitu banyak upaya untuk melamar dalam waktu yang tetap dan waktu itu tampaknya selalu kurang dari waktu yang diperlukan untuk melakukan pekerjaan yang sempurna, jadi karena tidak adanya jadwal yang sempurna kita harus puas dengan perkiraan.

Metrik yang saya temukan berguna dalam membuat perkiraan yang baik adalah Crap4J . Sekarang sudah mati tetapi Anda dapat dengan mudah port / mengimplementasikannya sendiri. Crap4J untuk mencoba menghubungkan cakupan kode dengan kompleksitas siklomatik dengan menyiratkan kode yang lebih rumit (jika, ketika, saat, dll.) Harus memiliki cakupan tes yang lebih tinggi. Bagi saya ide sederhana ini benar-benar berdering. Saya ingin memahami di mana ada risiko dalam basis kode saya, dan satu risiko yang sangat penting adalah kompleksitas. Jadi dengan menggunakan alat ini saya dapat dengan cepat menilai seberapa berisiko basis kode saya. Jika rumit, cakupannya sebaiknya naik. Jika tidak, saya tidak perlu membuang waktu mencoba untuk mendapatkan setiap baris kode tertutup.

Tentu saja ini hanya satu metrik dan YMMV. Anda harus meluangkan waktu dengannya untuk memahami apakah itu masuk akal bagi Anda dan jika itu akan memberi tim Anda perasaan yang bisa dipercaya di mana proyek itu berada.

Saya tidak akan mengatakan bahwa kembali dan mencakup kode yang ada adalah rute terbaik ke depan. Saya berpendapat bahwa masuk akal untuk menulis tes meliputi untuk setiap kode baru yang Anda tulis dan atau kode apa pun yang Anda ubah.

Ketika bug ditemukan, tulis tes yang gagal karena bug itu dan perbaiki bug sehingga tes berubah menjadi hijau. Masukkan komentar untuk bug apa tes ini ditulis.

Tujuannya adalah untuk memiliki keyakinan yang cukup dalam pengujian Anda sehingga Anda dapat membuat perubahan tanpa memperhatikan efek samping yang tidak diharapkan. Lihat Bekerja Efektif dengan Kode Lama untuk ringkasan pendekatan yang baik untuk menjinakkan kode yang belum diuji.