Bagaimana Anda membuat pengujian unit lebih menyenangkan? [Tutup]

Jika Anda selalu menyukai pengujian unit, bagus untuk Anda! Tetapi bagi mereka yang kurang beruntung yang tidak terlahir dengan kesukaan akan hal itu, bagaimana Anda bisa membuat tugas ini lebih menyenangkan?

Ini bukan pertanyaan "apa cara yang benar untuk menguji unit". Saya hanya ingin tahu sedikit trik pribadi yang mengurangi kebosanan (berani saya katakan) dalam menulis unit test.

Pertama, saya setuju dengan Anda - jika Anda menulis tes unit Anda pada kode yang sudah selesai, atau Anda secara manual menguji kode Anda, saya menemukan itu sangat membosankan juga.

Saya menemukan ada dua cara pengujian unit untuk saya yang benar-benar membuatnya menyenangkan:

1. Dengan menggunakan Test Driven Development (TDD) - menulis tes terlebih dahulu memungkinkan saya untuk memikirkan fungsionalitas atau perilaku berikutnya yang saya butuhkan dalam kode saya. Saya menemukan mengemudi menuju tujuan akhir saya dalam langkah-langkah kecil dan melihat kemajuan nyata menuju tujuan itu setiap beberapa menit sangat bermanfaat dan menyenangkan.
2. Ketika ada bug, daripada langsung ke debugger, itu adalah tantangan yang menyenangkan untuk mengetahui cara menulis unit test gagal yang mereproduksi bug. Sangat memuaskan akhirnya mengetahui keadaan yang membuat kode Anda gagal, lalu memperbaikinya dan menonton bilah berubah hijau untuk tes gagal baru (dan tetap hijau untuk semua tes yang ada).

Keunggulan sombong.

Saya hanya setengah bercanda. "Lihat aku, kembangkan kebiasaan pemrograman yang bagus! Hal-hal 'pengujian unit' ini adalah sesuatu yang Aku Dari Sepuluh Tahun Lalu tidak akan pernah dilakukan - bodoh sekali! Dan pikirkan saja semua bug yang akan kudapatkan sebagai hasil dari pekerjaan membosankan dan melelahkan yang saya lakukan saat ini - kode saya akan luar biasa! Saya pasti akan mendapat kenaikan gaji! * "

* - Tidak, saya tidak akan.

Saya merasa seperti berolahraga atau makan sehat; sampai manfaat nyata benar-benar menendang ("Bola suci, saya benar-benar menangkap omong kosong kesalahan regresi yang akan menyelinap ke dalam produksi!"), kebanggaan moral mengetahui bahwa Anda sedang melakukan Hal yang Benar dapat membantu membawa Anda melalui.

Pertama, saya hampir tidak pernah duduk di sana dan menulis unit test. Tes unit adalah sarana untuk mencapai tujuan, bukan tujuan dalam diri mereka sendiri. Mereka adalah cara menjawab "apakah kode ini melakukan tugas dasar yang seharusnya."

Misalnya, beberapa orang akan menulis fungsi, dan kemudian membuka sesi interaktif untuk mengujinya pada beberapa nilai dan memastikan itu berfungsi:

def fact x
  if x == 0
    1
  else 
    x * fact(x-1)
  end
end

>> fact 10
=> 3628800
>> fact 7
=> 5040

Tetapi sekarang Anda menemukan bug:

>> fact -1
SystemStackError: stack level too deep
    from (irb):2:in `fact'
    from (irb):5:in `fact'
    from (irb):10

Jadi Anda memperbaikinya:

def fact x
  if x < 0
    raise "Can't take the factorial of a negative number"
  elsif x == 0
    1
  else 
    x * fact(x-1)
  end
end

>> fact -1
RuntimeError: Can't take the factorial of a negative number
    from (irb):3:in `fact'
    from (irb):10

Tapi sekarang Anda benar-benar harus menguji untuk memastikan itu masih berfungsi:

>> fact 10
=> 3628800
>> fact 7
=> 5040

Seperti yang Anda lihat, Anda terus mengulangi tes yang sama ... dan Anda harus membandingkan hasilnya secara visual. Unit testing adalah cara menghindari pengulangan dalam kasus ini; itu mengurangi berapa banyak pekerjaan yang perlu Anda lakukan. Dan sementara ini adalah contoh kecil yang konyol, di dunia nyata, itu menjadi semakin penting, dan semakin sulit untuk menguji secara manual. Apa artinya ini, tentu saja, adalah bahwa orang tidak menguji komponen individu; mereka hanya menguji keseluruhan program. Tapi kemudian bug muncul, dan mereka jauh lebih sulit ditemukan. Atau bug terjadi, dan mereka diperbaiki, tetapi seseorang memperkenalkan bug yang sama sekali lagi, karena tidak ada yang menambahkan test case untuk memastikan itu tidak terjadi. Atau seseorang melihat sepotong besar kode, dan berkata, "Saya tidak tahu apa yang harus dilakukan, karena tidak didokumentasikan dan tidak memiliki tes ... jika saya memperbaiki bug ini, saya tidak tahu apakah saya akan merusak sesuatu yang lain tergantung padanya; mungkin saya hanya akan menulis ulang ini dari awal. "

Tes unit mengurangi semua pekerjaan ekstra dalam kasus ini. Cara terbaik untuk membuat mereka senang adalah memastikan bahwa orang memahami semua pekerjaan yang mereka gantikan, dan fleksibilitas ekstra yang datang dari mengetahui apa yang seharusnya dilakukan oleh setiap bagian kode. Pada tingkat tertentu, orang perlu memiliki sedikit lebih banyak pengalaman dalam menulis dan memelihara basis kode yang besar untuk memahami betapa pentingnya pengujian unit; jika semua kode mereka adalah sesuatu yang mereka tulis sekali dan buang, mereka tidak akan pernah mendapatkannya.

Dan tes unit tidak harus ditulis setelah fakta, sebagai tugas tambahan setelah Anda memiliki kode yang Anda "tahu" sudah berfungsi. Tes unit harus ditulis terlebih dahulu, atau paling tidak (karena Anda terkadang lupa untuk menuliskannya terlebih dahulu) tepat setelah menulis kode yang dimaksud. Ini disebut pengembangan yang digerakkan oleh pengujian, dan ini dapat membantu membuat API Anda lebih baik; jika Anda menulis tes yang menggunakan API terlebih dahulu, Anda akan belajar di mana API itu menyakitkan untuk digunakan bahkan sebelum Anda menulis kode, dan dapat mendesain ulang jauh lebih mudah daripada jika Anda hanya menambahkan tes sesudahnya.

Saya tidak tahu Yang pasti membuat pengujian unit lebih menyenangkan bagi saya adalah memikirkan semua debugging yang membuat frustrasi, panjang, membosankan, dan tidak menguntungkan yang tidak akan saya lalui setiap kali saya membuat perubahan dalam perangkat lunak :)

Superioritas puas yang Anda rasakan ketika Anda memeriksa kode yang sangat solid, kuat, dan stabil. Dan jika Anda menulis tes unit dengan alat cakupan kode, Anda dapat membanggakan dalam komentar cek Anda bahwa cakupan kode Anda adalah 90% atau lebih tinggi.

Jelas, ada kepuasan dari pengembangan tes pertama dan perasaan yang Anda dapatkan ketika desain dan tes Anda bergabung. Namun, menulis tes untuk kode yang sudah ada sebelumnya / legacy dapat mematikan pikiran dan membuat frustrasi. Ketika proyek kami berada dalam pola pemeliharaan, saya menulis tes untuk kode yang belum diuji menggunakan laporan cakupan sebagai permainan. Anda dapat membuat sedikit kompetisi dengan diri sendiri dan / atau orang lain untuk meningkatkan angka cakupan. Memang, Anda mungkin mengambilnya terlalu jauh dan membuat beberapa tes buruk, tetapi itu bisa menjadi motivator yang baik.

Cobalah untuk masuk ke Aliran . Tetapkan tujuan yang sulit, tetapi dapat dicapai untuk diri sendiri. Apa yang bisa menjadi tujuan dalam pengujian unit? Misalnya, cobalah untuk menulis lebih cepat sambil menjaga kualitas. Tes unit tidak membutuhkan terlalu banyak pemikiran sehingga kesalahan tidak mungkin terjadi. Berkonsentrasilah pada tujuan Anda dan sering-seringlah memeriksa untuk melihat apakah Anda sudah mendekati itu.

Terkadang untuk membuat saya termotivasi, saya akan menuliskan "cakupan kode" saya saat ini di awal hari. Kemudian setiap kali saya menulis tes dan lulus, saya akan menjalankan suite, dan memperbarui nomor cakupan. Sangat menyenangkan, dan mengingatkan saya mengapa saya melakukan ini. (Ada alasan lain juga, tapi aku suka angkanya. Mungkin itu hanya aku!)

Dengan tidak mencoba menipu diri sendiri bahwa saya dapat menipu pikiran saya untuk berpikir bahwa pengujian unit bisa menyenangkan untuk periode waktu yang berkelanjutan.

Menerima kenyataan bahwa pengujian unit tidak ada untuk dinikmati sangat membantu saya, membuat saya sadar bahwa saya sedang mencari sesuatu di tempat yang seharusnya tidak pernah ada.

Dalam perjalanan mental singkat ini ketika saya sampai pada titik merasakan pengujian unit untuk menjadi apa itu sebenarnya, yaitu tugas yang kejam, tak tertahankan, dan sangat menghancurkan jiwa, saya bertanya pada diri sendiri apakah saya mampu melepaskannya, yaitu tidak memiliki jaminan tinggi tentang kebenaran fungsional.

Selalu, jawabannya adalah tegas "tidak".

Setelah menerima nasib saya, saya terus mendorong benda-benda persegi ini dengan huruf, angka, dan simbol pada mereka di depan saya, yang kita sebut keyboard, mengetahui dari pengalaman tangan pertama bahwa dengan setiap klik keyboard, akhir pengujian unit lebih dekat daripada itu telah pernah pernah.