Apakah ide yang baik untuk mengukur kinerja suatu metode dengan menggunakan timeout uji unit?

Dalam sebuah proyek di mana ada persyaratan non-fungsional yang menentukan waktu eksekusi maksimum untuk tindakan tertentu, QA harus memeriksa kinerja tindakan ini pada mesin khusus menggunakan perangkat keras yang tepat di bawah beban yang tepat, baik perangkat keras dan beban yang ditentukan dalam persyaratan.

Di sisi lain, beberapa perubahan yang salah pada kode sumber dapat sangat mempengaruhi kinerja. Memperhatikan dampak negatif ini sejak dini , sebelum kode sumber mencapai kendali sumber dan diverifikasi oleh departemen QA, dapat bermanfaat dalam hal waktu yang hilang oleh departemen QA yang melaporkan masalah tersebut, dan oleh pengembang yang memperbaikinya beberapa komitmen kemudian.

Untuk melakukan ini, apakah itu ide yang bagus:

• Untuk menggunakan unit test untuk memiliki gagasan tentang waktu yang dihabiskan melaksanakan action² sama n kali,

• Untuk menggunakan batas waktu uji setiap melalui [TestMethod, Timeout(200)]atribut dalam C #?

Saya mengharapkan beberapa masalah dengan pendekatan ini:

• Secara konseptual , tes unit tidak benar-benar untuk itu: mereka diharapkan untuk menguji sebagian kecil kode, tidak lebih: pemeriksaan persyaratan fungsional, atau tes integrasi, atau tes kinerja.

• Apakah batas waktu uji unit dalam Visual Studio benar-benar mengukur apa yang diharapkan untuk diukur, dengan mempertimbangkan bahwa inisialisasi dan pembersihan tidak ada untuk tes tersebut atau terlalu pendek untuk mempengaruhi hasil?

• Mengukur kinerja dengan cara ini jelek. Menjalankan benchmark pada mesin apa saja — terlepas dari perangkat keras, beban, dll. Seperti melakukan benchmark yang menunjukkan bahwa satu produk basis data selalu lebih cepat daripada yang lain. Di sisi lain, saya tidak berharap unit test itu menjadi hasil yang pasti, atau sesuatu yang digunakan oleh departemen QA . Unit test tersebut akan digunakan hanya untuk memberikan gambaran umum tentang kinerja yang diharapkan, dan pada dasarnya untuk mengingatkan pengembang bahwa modifikasi terakhirnya merusak sesuatu, sangat mempengaruhi kinerja .

• Pengembangan Tes Didorong (TDD) tidak mungkin untuk tes tersebut. Bagaimana ini bisa gagal, sejak awal, sebelum mulai mengimplementasikan kode?

• Terlalu banyak tes kinerja akan memengaruhi waktu yang diperlukan untuk menjalankan tes, sehingga pendekatan ini terbatas pada tindakan singkat saja.

Mempertimbangkan masalah-masalah itu, saya masih merasa menarik untuk menggunakan tes unit tersebut jika dikombinasikan dengan metrik kinerja nyata oleh departemen QA.

Apakah aku salah? Apakah ada masalah lain yang membuatnya benar-benar tidak dapat diterima untuk menggunakan tes unit untuk ini?

Jika saya salah, apa cara yang benar untuk mengingatkan pengembang bahwa perubahan kode sumber sangat memengaruhi kinerja, sebelum kode sumber mencapai kontrol sumber dan diverifikasi oleh departemen QA?

^{¹ Sebenarnya, tes unit diharapkan hanya berjalan pada PC pengembang yang memiliki kinerja perangkat keras yang sebanding, yang mengurangi kesenjangan antara mesin tercepat yang tidak akan pernah bisa gagal dalam tes kinerja, dan mesin paling lambat yang tidak akan pernah berhasil melewatinya.}

^{² Dengan tindakan, maksud saya sepotong kode yang agak pendek yang menghabiskan beberapa milidetik untuk dijalankan.}

Kami menggunakan pendekatan ini juga, yaitu kami memiliki tes yang mengukur runtime di bawah beberapa skenario beban yang ditentukan pada mesin yang diberikan. Mungkin penting untuk menunjukkan, bahwa kami tidak memasukkan ini dalam tes unit normal. Tes unit pada dasarnya dijalankan oleh setiap pengembang pada mesin pengembang sebelum melakukan perubahan. Lihat di bawah untuk alasan mengapa ini tidak masuk akal untuk tes kinerja (setidaknya dalam kasus kami). Sebagai gantinya kami menjalankan tes kinerja sebagai bagian dari tes integrasi.

Anda menunjukkan dengan benar, bahwa ini seharusnya tidak mengesampingkan verifikasi. Kami tidak menganggap pengujian kami sebagai pengujian persyaratan non-fungsional. Sebaliknya, kami menganggapnya hanya sebagai indikator masalah potensial.

Saya tidak yakin tentang produk Anda, tetapi dalam kasus kami, jika kinerjanya tidak mencukupi, itu berarti banyak pekerjaan diperlukan untuk "memperbaiki" itu. Jadi waktu berbalik, ketika kita menyerahkan ini sepenuhnya ke QA adalah mengerikan. Selain itu, perbaikan kinerja akan berdampak parah pada sebagian besar basis kode, yang membuat pekerjaan QA sebelumnya batal. Secara keseluruhan, alur kerja yang sangat tidak efisien dan tidak memuaskan.

Yang sedang berkata, berikut adalah beberapa poin untuk masalah Anda masing-masing:

• secara konseptual: memang benar, bahwa ini bukan tentang tes unit. Tapi selama semua orang sadar, bahwa tes tidak seharusnya memverifikasi apa pun yang harus dilakukan QA, tidak apa-apa.

• Visual Studio: tidak dapat mengatakan apa-apa tentang itu, karena kami tidak menggunakan kerangka uji unit dari VS.

• Mesin: Tergantung pada produk. Jika produk Anda adalah sesuatu yang dikembangkan untuk pengguna akhir dengan mesin desktop khusus individu, maka sebenarnya lebih realistis untuk melakukan tes pada mesin pengembang yang berbeda. Dalam kasus kami, kami mengirimkan produk untuk mesin dengan spesifikasi yang diberikan dan kami menjalankan tes kinerja ini hanya pada mesin tersebut. Memang, tidak ada gunanya mengukur kinerja pada mesin pengembang dual-core Anda, ketika klien akhirnya akan menjalankan 16 core atau lebih.

• TDD: Meskipun kegagalan awal adalah tipikal, itu bukan keharusan. Faktanya, menulis tes-tes ini lebih awal membuatnya lebih berfungsi sebagai tes regresi daripada tes unit tradisional. Bahwa tes berhasil sejak awal tidak ada masalah. Tetapi Anda mendapatkan keuntungan, bahwa setiap kali pengembang menambahkan fungsionalitas yang memperlambat hal-hal, karena ia tidak mengetahui persyaratan kinerja non-fungsional, tes TDD ini akan menemukannya. Sering terjadi, dan ini umpan balik yang luar biasa. Bayangkan dalam pekerjaan sehari-hari Anda: Anda menulis kode, Anda mengkomitnya, Anda pergi makan siang dan ketika Anda kembali, sistem build memberi tahu Anda bahwa kode ini ketika dijalankan di lingkungan beban berat terlalu lambat. Itu cukup baik bagi saya untuk menerima, bahwa tes TDD pada awalnya tidak gagal.

• Run-time: Seperti yang disebutkan, kami tidak menjalankan tes ini pada mesin pengembang, melainkan sebagai bagian dari sistem build dalam semacam tes integrasi.

Saya sebagian besar sejalan dengan pemikiran Anda. Hanya memasang alasan saya dengan aliran independen.

1. Buat itu berfungsi sebelum membuatnya lebih baik / lebih cepat
Sebelum kode memberikan ukuran kinerja apa pun (apalagi jaminan) itu harus terlebih dahulu dibuat benar yaitu membuatnya berfungsi secara fungsional. Mengoptimalkan kode yang salah secara fungsional tidak hanya membuang waktu, tetapi juga menghambat pengembangan.

2. Kinerja suatu sistem masuk akal hanya pada sistem penuh.
Biasanya, kinerja yang berarti selalu bergantung pada infrastruktur yang diberikan dan itu hanya harus dilihat di bawah sistem penuh. Sebagai contoh, selama tes tiruan jika modul menerima jawaban dari file teks lokal tetapi dalam lingkungan produksi ia mengambil dari database, Anda sebelumnya

3. Penskalaan kinerja harus dilakukan dengan objektif
Setelah Anda memiliki sistem fungsional, Anda perlu menganalisis kinerja sistem dan menemukan hambatan untuk memahami di mana Anda perlu meningkatkan kinerja. Secara buta mencoba untuk mengoptimalkan setiap metode bahkan sebelum Anda tahu kinerja sistem penuh dapat menimbulkan jumlah pekerjaan yang tidak berguna (mengoptimalkan metode yang tidak masalah) dan dapat membuat kode Anda membengkak secara tidak perlu.

Saya tidak berhenti menyadari fungsionalitas Visual studio, tetapi umumnya Anda memerlukan alat profil yang lebih luas.

Saya punya tugas serupa beberapa waktu lalu dan solusi terakhir ada di suatu tempat di tengah-tengah antara pengujian unit dan pengujian kinerja otomatis penuh.

Beberapa pertimbangan tanpa urutan tertentu, yang mungkin berguna:

• Pengujian kinerja oleh QA adalah padat karya dan memiliki jadwal sendiri (katakanlah, sekali dalam iterasi), sehingga menekan kontrol sumber tidak menjadi masalah.
• Sistem kami besar dan modular, unit-test terlalu granular untuk kebutuhan kami, dan kami telah membuat unit-test "gemuk" khusus yang dirancang dengan hati-hati untuk memicu masalah kinerja di bidang minat tertentu (mereka dikategorikan juga, tetapi ini adalah detail implementasi).
• Kendala biasa untuk unit-test masih berlaku: mereka harus kecil, cepat dan to the point.
• Untuk mengecualikan pengaruh kerangka uji, mereka dijalankan oleh pembungkus khusus, jadi kami tahu persis berapa lama waktu yang diperlukan untuk operasi yang diberikan.
• Dimungkinkan untuk menuliskannya sebelum implementasi aktual selesai (hasilnya mungkin tidak relevan atau berguna, tergantung pada prosesnya, mungkin pengembang masih bereksperimen dengan implementasi dan ingin melihat bagaimana kelanjutannya).
• Mereka dijalankan oleh server CI setelah masing-masing membangun, sehingga total waktu berjalan harus dijaga relatif singkat (jika tidak demikian, menjadi lebih sulit untuk menentukan perubahan yang tepat memicu masalah).
• Server CI sangat kuat dan perangkat kerasnya telah diperbaiki, jadi kami menghitung ini sebagai mesin yang didedikasikan (dimungkinkan untuk menggunakan server yang benar-benar didedikasikan dengan menggunakan agen build jarak jauh).
• Pembungkus uji mengumpulkan semua informasi yang relevan (spesifikasi perangkat keras, nama / kategori uji, beban sistem, waktu yang berlalu, dll.) Dan mengekspornya sebagai laporan atau ke basis data.
• Kami memiliki gadget untuk JIRA yang menarik laporan tersebut dan menggambar grafik yang bagus dengan nama / kategori / nomor build dengan beberapa kontrol (overlay rilis sebelumnya ke yang sekarang, dll.), Sehingga pengembang dapat dengan cepat melihat dampaknya dan manajer dapat memperoleh gambaran umum (Beberapa merah, semua hijau, Anda tahu, ini penting bagi mereka).
• Dimungkinkan untuk menganalisis bagaimana proyek berjalan seiring waktu dengan menggunakan statistik yang dikumpulkan.

Jadi, pada akhirnya, kami memiliki sistem yang skalabel, fleksibel, dan dapat diprediksi yang dapat dengan cepat disesuaikan dengan kebutuhan khusus kami. Tetapi perlu beberapa upaya untuk mengimplementasikannya.

Kembali ke pertanyaan. Tes unit secara konseptual bukan untuk itu, tetapi Anda dapat memanfaatkan fitur kerangka pengujian Anda. Saya tidak pernah menganggap batas waktu pengujian sebagai alat untuk mengukur, itu hanya jaring pengaman untuk hang dan hal-hal semacam itu. Tetapi jika pendekatan Anda saat ini bekerja untuk Anda, maka terus gunakan itu, menjadi praktis. Anda selalu bisa berfantasi nanti jika perlu.

Saya pikir Anda baik-baik saja. Ini persis titik memiliki unit timeout tes: untuk memeriksa apakah ada sesuatu yang mengambil jalan, jauh lebih lama dari yang seharusnya. Ada batasan untuk pendekatan ini, tetapi Anda tampaknya sudah menyadarinya, jadi selama Anda mengingat keterbatasan itu, saya tidak melihat masalah.