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.
MbUnitperpustakaan telah mengubah hidup saya. Pengujian otomatis penting. Pengujian otomatis menghemat waktu. Pengujian otomatis menghemat uang. Pengujian otomatis dapat menyelamatkan nyawa. Pengujian otomatis adalah satu-satunya cara. Pengujian otomatis adalah jaring pengaman lainnya. Ketika saya adalah satu dari 50 orang yang mengerjakan arsitektur besar, saya merasa seperti batu bata di dinding. Dengan unit test saya memegang kendali.