Majikan saya menjalankan kompetisi hari pengujian unit bulanan. Satu hari penuh didedikasikan untuk menulis unit test - jelas kami melakukan lebih banyak pengujian sepanjang bulan, tetapi ini adalah satu hari penuh - dan "pemenang" kompetisi diberikan hadiah. Namun, kami sulit menentukan siapa pemenangnya.
Kami memberikan poin untuk setiap test case. Jadi jika Anda menulis unit test seperti ini ...
for (int i = 0; i < 100; i++) {
assertTrue(i*i, square(i));
}Anda akan diberikan 100 poin. Jelas ini adalah contoh sederhana tetapi menunjukkan masalah dengan menetapkan "poin" untuk setiap kasus uji.
Kami terutama toko Java & Javascript. Jadi saya menyarankan menghitung jumlah cabang kode yang diuji sebagai metrik. Kami dapat dengan mudah menghitung cabang yang diuji melalui alat cakupan kode (seperti EclEmma). Namun, tidak yakin bagaimana kami akan melakukan ini dengan tes Selenium kami dan mendapatkan cakupan kode pada sumber Javascript (ada ide?)
Adakah yang punya saran tentang bagaimana kita bisa lebih baik menentukan pemenang kompetisi ini?
Edit
Saya tahu cara menulis unit test, saya tahu cara menulis unit test yang efektif, saya tidak perlu bantuan menentukan apa yang harus diuji. Saya tidak memiliki kendali atas kompetisi ini - kompetisi akan berlanjut. Jadi saya menambahkan beberapa input untuk membuatnya lebih baik atau menjalankan game tes (ya, saya game mereka. Tentu saja saya game mereka. Ada hadiah yang harus dimenangkan)
Edit
Pertanyaan ini di sini jelas bukan duplikat, meskipun berisi informasi yang berguna tentang bagaimana menemukan kasus pengujian yang baik, ini tidak memberikan metrik yang berguna untuk mengevaluasi kompetisi.
sumber
Jawaban:
Satu-satunya hal yang masuk akal bagi saya adalah dengan memilih - setiap dev dapat memberikan beberapa poin untuk setiap tes dev lainnya (kecuali miliknya sendiri). Mungkin 3 poin untuk tes yang menurutnya adalah yang "paling efektif", 2 poin untuk yang kedua dan satu ke yang ketiga. Tes dengan poin terbanyak menang. Ini mungkin memberikan hasil yang lebih baik ketika penugasan poin dilakukan tanpa mengetahui sebelumnya siapa yang menulis tes tertentu.
Sebagai bonus, Anda akan mendapatkan semua tes Anda ditinjau.
sumber
Saya akan memberi orang ini 0 poin (bahkan jika tes itu menguji sesuatu yang benar-benar relevan), karena pernyataan dalam satu lingkaran tidak masuk akal dan tes dengan banyak pernyataan (terutama dalam bentuk lingkaran atau peta) sulit untuk dikerjakan.
Masalahnya adalah pada dasarnya memiliki metrik yang tidak dapat [dengan mudah] ditipu. Metrik yang secara eksklusif didasarkan pada jumlah konfirmasi persis sama dengan pengembang berbayar per LOC tertulis. Seperti halnya bayar-oleh-LOC yang mengarah pada kode yang besar dan tidak mungkin dipertahankan, kebijakan perusahaan Anda yang sebenarnya mengarah pada tes yang tidak berguna dan mungkin ditulis dengan buruk.
Jika jumlah penegasan tidak relevan, jumlah tes juga tidak relevan. Ini juga kasus untuk banyak metrik (termasuk yang digabungkan) yang bisa dibayangkan untuk situasi semacam ini.
Idealnya, Anda akan menerapkan pendekatan sistemik. Dalam praktiknya, ini hampir tidak dapat bekerja di sebagian besar perusahaan pengembang perangkat lunak. Jadi saya dapat menyarankan beberapa hal lain:
Menggunakan ulasan pasangan untuk tes dan memiliki sesuatu yang mirip dengan jumlah WTF per menit metrik.
Ukur dampak tes-tes tersebut dari waktu ke waktu terhadap jumlah bug . Ini memiliki beberapa manfaat:
Gunakan cakupan cabang , tetapi gabungkan dengan metrik lainnya (serta ulasan). Cakupan cabang memiliki manfaatnya, tetapi menguji kode CRUD hanya untuk mendapatkan nilai yang lebih baik bukanlah cara terbaik untuk menghabiskan waktu pengembang.
Putuskan bersama-sama apa saja metrik yang ingin Anda terapkan untuk saat ini (keputusan semacam itu mungkin tidak disambut atau bahkan dimungkinkan di beberapa perusahaan dan tim). Tinjau dan ubah metrik sesering mungkin, pilih metrik yang menjadi lebih relevan, dan pastikan semua orang memahami dengan jelas apa yang diukur dan bagaimana.
sumber
Saya kira majikan Anda mengatur hari pengujian unit ini untuk memberi Anda insentif kepada orang-orang untuk menemukan bug, untuk mencapai cakupan kode yang lebih besar, dan pada akhirnya memiliki lebih banyak tes, yang berguna selamanya setelahnya.
Jadi, saya pikir masuk akal jika pemenangnya adalah pengembang yang menemukan bug terbanyak, atau pengembang yang pengujiannya mencapai peningkatan cakupan kode terbesar.
Sebuah tes akan memberi Anda poin jika itu menyebabkan entri baru dibuka di sistem pelacakan masalah / bug / cacat Anda. Jika sebuah entri sudah terbuka untuk masalah itu, itu tidak masuk hitungan. Juga, seperti yang disarankan dalam komentar, bug dalam kode Anda sendiri tidak masuk hitungan; hanya bug dalam kode orang lain yang harus dihitung. Sayangnya, pendekatan ini tidak memberikan kepuasan instan karena mungkin perlu beberapa hari sampai semua tes gagal diselesaikan dan masalah terkait dibuka. Juga, ini mungkin tidak selalu berhasil; ketika sistem Anda matang, mungkin mulai menjadi sangat jarang untuk menemukan bug dengan menambahkan tes.
Peningkatan cakupan kode mungkin memberikan pengukuran perbaikan yang lebih obyektif yang diwakili oleh tes baru. Pertama, total cakupan kode harus direkam sehari sebelum kompetisi. Kemudian, setiap pengembang perlu menunjukkan peningkatan cakupan kode yang dihasilkan dari pengujian mereka sendiri, tanpa memperhitungkan peningkatan cakupan kode yang dihasilkan dari tes yang ditulis oleh pengembang lain. Ini berarti bahwa Anda mungkin membutuhkan wasit yang akan mengunjungi setiap mesin pengembang dan mencatat cakupan kode baru sebelum tes siapa pun dilakukan.
Kebetulan, mempertimbangkan cakupan kode memberikan imbalan yang adil bagi orang yang menulis tes nyata, alih-alih melakukan hal-hal konyol seperti contoh yang Anda berikan dalam pertanyaan.
sumber