Sudahkah unit test generator membantu Anda ketika bekerja dengan kode lawas?

Saya melihat basis kode kecil (~ 70kLOC termasuk yang dihasilkan) C # (.NET 4.0, some Silverlight) yang memiliki cakupan tes sangat rendah. Kode itu sendiri berfungsi karena telah lulus pengujian penerimaan pengguna, tetapi rapuh dan di beberapa daerah tidak diperhitungkan dengan baik. Saya ingin menambahkan cakupan uji unit yang solid di sekitar kode lama menggunakan tersangka biasa (NMock, NUnit, StatLight untuk bit Silverlight).

Pendekatan normal saya adalah mulai bekerja melalui proyek, pengujian & refactoring unit, sampai saya puas dengan keadaan kode. Saya sudah melakukan ini berkali-kali di masa lalu, dan itu berhasil dengan baik.

Namun, kali ini saya berpikir untuk menggunakan generator tes (khususnya Pex ) untuk membuat kerangka uji, kemudian secara manual menyempurnakannya.

Pertanyaan saya adalah: apakah Anda pernah menggunakan generator unit test di masa lalu ketika mulai bekerja pada basis kode warisan, dan jika demikian, apakah Anda akan merekomendasikan mereka?

Ketakutan saya adalah bahwa tes yang dihasilkan akan kehilangan nuansa semantik dari basis kode, yang mengarah ke situasi yang menakutkan memiliki tes demi cakupan metrik, daripada tes yang dengan jelas mengungkapkan perilaku yang dimaksud dalam kode.

unit-testing legacy

— Duncan Bayne
sumber

Saya mencoba PeX sekali dan hasilnya, yah, katakanlah, tidak terlalu memuaskan - YMMV. Jangan berharap alat seperti itu untuk "memahami" kode Anda dan persyaratan fungsionalnya - itu tidak ketinggalan hanya "nuansa semantik", itu merindukan seluruh semantik. Selanjutnya, ketika Anda mulai dengan basis kode lawas, Anda biasanya tidak akan memulai dengan tes unit terlebih dahulu, tetapi dengan tes sistem atau integrasi; yang jelas bukan untuk apa PEX diciptakan.

— Doc Brown

Saya sarankan melihat hal-hal sedikit berbeda. Menambahkan kode uji unit baru ke aplikasi yang sudah ada tanpa insiden mungkin tidak memberi Anda hasil terbaik. Jika Anda melakukan ini untuk membiasakan diri dengan basis kode atau Anda benar-benar punya waktu untuk membunuh dan ingin menguji generator uji maka abaikan komentar saya.

Agar pragmatis, Anda harus memeriksa semua daftar bug. Kemudian buat unit test untuk masing-masing bug, menghasilkan bagaimana seharusnya berperilaku. Idealnya, Anda hanya akan menambahkan kode baru untuk setiap bug saat Anda mencapainya.

Waktu untuk menambahkan kode uji unit:

Menambahkan fungsi baru
Kode ulang faktor
Memperbaiki bug
Mempelajari apa yang dilakukan kode
Buktikan ada bug

Sulit untuk mengukur nilai penambahan unit test setelah fakta.

Saya biasanya tidak membiarkan diri saya menulis jawaban yang bertentangan dengan keinginan si penanya, tetapi saya merasa ini adalah pelajaran yang baik untuk disampaikan.

— Andrew T Finnell
sumber

Saya 100% setuju dengan Anda di sana - pertanyaan ini muncul dari saya bertanya-tanya bagaimana cara terbaik untuk menghabiskan waktu luang. Praktik normal saya adalah menguji & refactor dalam proses memperbaiki bug, atau menambahkan fitur. Saya berharap beberapa orang mungkin dapat berbagi beberapa kisah perang di daerah ini ...

— Duncan Bayne

+1, Mengambil gambar untuk liputan setelah faktanya biasanya tidak produktif. Memiliki tes pada bug tetap yang mencegah regresi sangat produktif. Regresi suatu bug bisa sangat menyebalkan bagi semua orang yang terlibat. Tes sangat cocok untuk membantu Anda menulis kode yang lebih baik. Baut pada tes biasanya menghasilkan tes di bawah standar. Saya pikir ketakutan OP didirikan dan rasio sinyal terhadap noise dari tes yang dihasilkan hanya akan menghalangi. Kode yang tidak diuji mungkin memiliki beberapa bit yang sangat bercabang di dalamnya. Alat yang menunjukkan bau kode mungkin lebih bermanfaat. Mungkin FXCop dan alat serupa.

— kevpie