Kompetisi Pengujian Unit


12

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.


Tidak terlalu. Saya menyadarinya dari awal
Shaun

2
Anda tampaknya belum menyadari sepenuhnya. Setiap ukuran siapa yang menulis kasus uji terbaik akan benar-benar subjektif atau memiliki masalah ini sampai batas tertentu. Metrik apa yang bekerja paling baik akan tergantung pada tujuan Anda untuk kompetisi ini dan pada seberapa matang (yaitu, tidak mungkin mengeksploitasi skor daripada menulis tes terbaik yang mereka bisa) para kontestan.

Sekali lagi, tidak. Saya menyadari mereka bisa dimainkan. Saya tidak memiliki kendali atas kompetisi ini tetapi ditanya "bagaimana kita bisa melakukan ini dengan lebih baik"
Shaun

13
Apakah ini dianggap sebagai peningkatan untuk tidak menjadikannya kompetisi? Mengapa semuanya harus menjadi kompetisi? Kenapa kamu tidak bisa berkolaborasi? Mungkin menyingkirkan beberapa unit test Anda yang tidak berguna dan membuat rangkaian tes asap dan regresi yang berguna akan sangat membantu.
Thomas Owens

1
Saya dengan Thomas ... pemenangnya harus basis kode / pelanggan karena kualitas kode ditingkatkan. Tetapkan tujuan keseluruhan / grup berdasarkan pada cakupan kode dari unit test ... + 5% dari yang sekarang atau apa pun. ... dan jangan permainan sistem untuk hadiah ... apa pun yang terjadi pada pekerjaan yang dilakukan dengan baik adalah hadiahnya sendiri?
JeffC

Jawaban:


15

Adakah yang punya saran tentang bagaimana kita bisa lebih baik menentukan pemenang kompetisi ini?

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.


2
Ini adalah pemikiran saya juga. Tidak ada cara lain untuk mengukur nilai tes.
Eric King

2
Ya, "pengujian yang baik" adalah hal yang subyektif yang perlu dipertimbangkan, baik oleh rekan sejawat atau pihak berwenang yang disegani. Mengejar metrik hanya akan menyebabkan banyak usaha sia-sia dan sedikit nilai nyata. Mungkin menarik untuk memiliki beberapa hadiah: uji paling imajinatif, penghargaan "pengujian sesuatu yang sebelumnya dianggap tidak dapat diuji", uji kinerja terbaik, uji paling efektif, uji paling tidak jelas, uji pandai, uji paling bernilai, uji yang paling mungkin dihargai oleh pengguna akhir ...
timday

6

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.

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:

  1. Menggunakan ulasan pasangan untuk tes dan memiliki sesuatu yang mirip dengan jumlah WTF per menit metrik.

  2. Ukur dampak tes-tes tersebut dari waktu ke waktu terhadap jumlah bug . Ini memiliki beberapa manfaat:

    • Tampak adil,
    • Sebenarnya bisa diukur jika Anda mengumpulkan cukup data tentang laporan bug dan nasibnya,
    • Benar-benar layak!
  3. 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.

  4. 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.


1
+1 untuk nol poin. Keberatan lainnya adalah AAA - Mengatur, Bertindak, Menegaskan; Tes Parameter; Tidak Menyalin kode implementasi ...
kemasan

5

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.


2
Kedengarannya menjanjikan ... tetapi kemudian perilaku "bermain sistem" berubah menjadi mengantarkan diri Anda pada kumpulan bug yang hanya diketahui untuk Anda yang akan "ditemukan" dalam kompetisi pengujian berikutnya ... dilbert.com/strip/1995-11 -13
timday

3
Salah satu opsi adalah hanya memberikan poin untuk bug dalam kode yang ditulis orang lain.
Cel Skeggs


@ col6y Anda benar, itu juga cukup penting. Sayangnya, masih ada cara untuk rig sistem. Misalnya, jika kode Anda memanggil kode saya untuk menyelesaikan tugasnya, kode saya dapat memastikan bahwa kode Anda mengalami "kecelakaan".
Mike Nakis

3
Saya tidak setuju. Tes unit, ketika baru ditulis, bukan untuk menemukan bug sejak awal , itu salah. Mereka dapat menemukan regresi berminggu-minggu atau berbulan-bulan setelah ditulis, tetapi kemungkinan besar sudah terlambat untuk memberikan metrik yang berguna untuk kompetisi. Anda biasanya menulis unit test setelah bug tertentu terjadi untuk memastikan Anda tidak akan mendapatkan jenis bug yang sama di kemudian hari.
Doc Brown
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.