Saya memiliki anekdot yang relevan dari sesuatu yang sedang terjadi saat ini untuk saya. Saya sedang mengerjakan proyek yang tidak menggunakan TDD. Orang-orang QA kami menggerakkan kami ke arah itu, tapi kami pakaian kecil dan itu merupakan proses yang panjang dan berlarut-larut.
Bagaimanapun , saya baru-baru ini menggunakan perpustakaan pihak ketiga untuk melakukan tugas tertentu. Ada masalah tentang penggunaan perpustakaan itu, jadi pada dasarnya saya harus menulis versi dari perpustakaan yang sama itu sendiri. Secara total, itu berakhir menjadi sekitar 5.000 baris kode yang dapat dieksekusi dan sekitar 2 bulan waktu saya. Saya tahu baris kode adalah metrik yang buruk, tetapi untuk jawaban ini saya merasa ini adalah indikator yang cukup baik.
Ada satu struktur data tertentu yang saya butuhkan yang akan memungkinkan saya untuk melacak jumlah bit yang sewenang-wenang. Karena proyek ini di Jawa, saya memilih Java BitSet
dan memodifikasinya sedikit (saya membutuhkan kemampuan untuk melacak yang terkemuka 0
juga, yang BitSet Java tidak lakukan untuk beberapa alasan .....). Setelah mencapai ~ 93% cakupan saya mulai menulis beberapa tes yang benar-benar akan menekankan sistem yang saya tulis. Saya perlu membandingkan aspek-aspek tertentu dari fungsionalitas untuk memastikan mereka cukup cepat untuk kebutuhan akhir saya. Tidak mengherankan, salah satu fungsi yang saya timpa dari BitSet
antarmuka adalah sangat lambat ketika berurusan dengan set bit besar (ratusan juta bit dalam kasus ini). Fungsi yang diganti lainnya bergantung pada fungsi yang satu ini, jadi itu sangat besar leher botol yang .
Apa yang akhirnya saya lakukan adalah pergi ke papan gambar, dan mencari cara untuk memanipulasi struktur yang mendasari BitSet
, yang merupakanlong[]
. Saya merancang algoritme, meminta masukan dari kolega, dan kemudian saya mulai menulis kode. Kemudian, saya menjalankan tes unit. Beberapa dari mereka rusak, dan yang menunjuk saya tepat ke tempat saya perlu mencari di algoritma saya untuk memperbaikinya. Setelah memperbaiki semua kesalahan dari unit test, saya dapat mengatakan bahwa fungsinya berfungsi sebagaimana mestinya. Paling tidak, saya bisa yakin bahwa algoritma baru ini bekerja sebaik algoritma sebelumnya.
Tentu saja, ini bukan bukti peluru. Jika ada bug dalam kode saya yang tidak diperiksa oleh unit test, maka saya tidak akan mengetahuinya. Tapi tentu saja, bug yang sama persis itu bisa ada dalam algoritma saya yang lebih lambat juga. Namun , saya dapat mengatakan dengan tingkat kepercayaan yang tinggi bahwa saya tidak perlu khawatir tentang output yang salah dari fungsi tertentu. Tes unit yang sudah ada menyelamatkan saya berjam-jam, mungkin berhari-hari, mencoba menguji algoritma baru untuk memastikan itu benar.
Itu adalah titik memiliki unit test terlepas dari TDD - artinya, unit test akan melakukan ini untuk Anda dalam TDD dan di luar TDD semua sama, ketika Anda akhirnya refactoring / mempertahankan kode. Tentu saja, ini harus dipasangkan dengan pengujian regresi reguler, pengujian asap, pengujian fuzzy, dll, tetapi pengujian unit , seperti namanya, menguji hal-hal pada tingkat atom terkecil yang mungkin, yang memberi Anda arahan tentang di mana kesalahan muncul.
Dalam kasus saya, tanpa tes unit yang ada, entah bagaimana saya harus menemukan metode untuk memastikan algoritma bekerja sepanjang waktu. Yang, pada akhirnya ... terdengar sangat mirip dengan pengujian unit , bukan?