Jawaban yang ada tentu baik, tetapi saya belum melihat ada yang membahas kesalahpahaman mendasar ini dalam pertanyaan:
pada setiap titik waktu semua unit test harus lulus
Tidak. Paling pasti, ini tidak akan benar. Saat saya sedang mengembangkan perangkat lunak, NCrunch paling sering berwarna cokelat (gagal bangun) atau merah (gagal uji).
Di mana NCrunch harus berwarna hijau (semua tes lulus) adalah ketika saya siap untuk mendorong komit ke server kontrol sumber, karena pada saat itu orang lain mungkin memerlukan ketergantungan pada kode saya.
Ini juga dimasukkan ke dalam topik membuat tes baru: tes harus menegaskan logika dan perilaku kode. Kondisi batas, kondisi kesalahan, dll. Ketika saya menulis tes baru, saya mencoba mengidentifikasi "hot spot" ini dalam kode.
Tes unit mendokumentasikan bagaimana saya mengharapkan kode saya dipanggil - prasyarat, keluaran yang diharapkan, dll.
Jika tes gagal mengikuti perubahan, saya perlu memutuskan apakah kode atau tes tersebut salah.
Sebagai catatan, pengujian unit terkadang berjalan seiring dengan Test Driven Development. Salah satu prinsip TDD adalah bahwa tes yang rusak adalah tiang petunjuk Anda. Ketika tes gagal, Anda harus memperbaiki kode sehingga tes lulus. Ini adalah contoh nyata dari awal minggu ini:
Latar Belakang : Saya menulis dan sekarang mendukung perpustakaan yang digunakan oleh pengembang kami yang digunakan untuk memvalidasi permintaan Oracle. Kami memiliki tes yang menyatakan bahwa kueri cocok dengan beberapa nilai yang diharapkan, yang menjadikan case penting (bukan di Oracle) dan dengan senang hati menyetujui kueri yang tidak valid selama mereka benar-benar cocok dengan nilai yang diharapkan.
Sebagai gantinya, perpustakaan saya mem-parsing kueri menggunakan Antlr dan sintaks Oracle 12c, dan kemudian membungkus berbagai pernyataan pada pohon sintaksis itu sendiri. Hal-hal seperti, itu valid (tidak ada kesalahan parse dinaikkan), semua parameternya dipenuhi oleh koleksi parameter, semua kolom yang diharapkan dibaca oleh pembaca data ada dalam kueri, dll. Semua ini adalah item yang telah diselipkan ke produksi pada berbagai waktu.
Salah satu rekan insinyur saya mengirimi saya pertanyaan pada hari Senin yang gagal (atau lebih tepatnya, berhasil ketika seharusnya gagal) selama akhir pekan. Perpustakaan saya mengatakan sintaksinya baik-baik saja, tetapi meledak ketika server mencoba menjalankannya. Dan ketika dia melihat permintaan, jelas mengapa:
UPDATE my_table(
SET column_1 = 'MyValue'
WHERE id_column = 123;
Saya memuat proyek dan menambahkan tes unit yang menyatakan bahwa permintaan ini seharusnya tidak valid. Jelas, tes gagal.
Berikutnya, saya debugged tes gagal, melangkah melalui kode di mana saya harapkan untuk membuang pengecualian, dan tahu bahwa Antlr itu menaikkan kesalahan pada paren terbuka, hanya saja tidak dengan cara kode sebelumnya mengharapkan. Saya memodifikasi kode, memverifikasi bahwa tes sekarang hijau (lulus) dan tidak ada orang lain yang rusak dalam proses, berkomitmen, dan mendorong.
Ini mungkin memakan waktu 20 menit, dan dalam prosesnya saya benar-benar meningkatkan perpustakaan secara signifikan karena sekarang mendukung seluruh jajaran kesalahan yang sebelumnya telah diabaikan. Jika saya tidak memiliki tes unit untuk perpustakaan, meneliti dan memperbaiki masalah ini bisa memakan waktu berjam-jam.