Rasa unit test tanpa TDD

Kami memiliki proyek baru (cukup besar) yang mulai, yang kami rencanakan untuk dikembangkan menggunakan TDD.

Gagasan TDD gagal (banyak alasan bisnis dan non-bisnis), tetapi saat ini kami memiliki percakapan - haruskah kami menulis unit test, atau tidak. Teman saya mengatakan bahwa tidak ada (atau hampir nol) akal dalam menulis tes unit tanpa TDD, kita harus fokus hanya pada tes integrasi. Saya percaya sebaliknya, bahwa masih ada beberapa pengertian dalam menulis tes unit biasa, hanya untuk membuat kode lebih futureproof. Apa yang kamu pikirkan?

Ditambahkan: Saya pikir ini bukan duplikat >> pertanyaan ini << - Saya mengerti perbedaan antara UT dan TDD. Pertanyaan saya bukan tentang perbedaan , tetapi tentang rasa menulis Tes Unit tanpa TDD.

TDD digunakan terutama (1) untuk memastikan cakupan, (2) dan untuk mendorong desain yang dapat dipertahankan, dimengerti, dan dapat diuji. Jika Anda tidak menggunakan TDD, Anda tidak mendapatkan cakupan kode yang dijamin.Tapi itu sama sekali tidak berarti bahwa Anda harus meninggalkan tujuan itu dan hidup bahagia dengan cakupan 0%.

Tes regresi diciptakan karena suatu alasan. Alasannya adalah bahwa dalam jangka panjang, mereka menghemat lebih banyak waktu Anda dalam kesalahan yang dicegah daripada mengambil upaya tambahan untuk menulis. Ini telah terbukti berulang kali. Oleh karena itu, kecuali jika Anda serius yakin bahwa organisasi Anda jauh, jauh lebih baik di rekayasa perangkat lunak dari semua guru yang merekomendasikan pengujian regresi (atau jika Anda berencana akan turun segera sehingga ada yang tidak lama berjalan untuk Anda), ya, Anda harus benar-benar memiliki unit test, untuk alasan persis yang berlaku untuk hampir setiap organisasi lain di dunia: karena mereka menangkap kesalahan lebih awal daripada tes integrasi, dan itu akan menghemat uang Anda. Tidak menulis mereka seperti melewatkan uang gratis hanya berbaring di jalan.

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 BitSetdan memodifikasinya sedikit (saya membutuhkan kemampuan untuk melacak yang terkemuka 0juga, 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 BitSetantarmuka 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?

Anda dapat membagi kode secara kasar menjadi 4 kategori:

1. Perubahan sederhana dan jarang.
2. Sederhana dan sering berubah.
3. Kompleks dan jarang berubah.
4. Kompleks dan sering berubah.

Tes unit menjadi lebih berharga (cenderung menangkap bug penting) semakin jauh ke bawah daftar Anda pergi. Dalam proyek pribadi saya, saya hampir selalu melakukan TDD pada kategori 4. Pada kategori 3 saya biasanya melakukan TDD kecuali pengujian manual lebih sederhana dan lebih cepat. Misalnya, kode antialiasing akan rumit untuk ditulis, tetapi jauh lebih mudah untuk memverifikasi secara visual daripada menulis unit test, jadi unit test hanya akan sepadan dengan saya jika kode itu sering berubah. Sisa kode saya hanya dimasukkan dalam unit test setelah saya menemukan bug dalam fungsi itu.

Terkadang sulit untuk mengetahui sebelumnya kategori apa yang cocok untuk suatu blok kode tertentu. Nilai TDD adalah Anda tidak sengaja melewatkan salah satu tes unit kompleks. Biaya TDD adalah semua waktu yang Anda habiskan untuk menulis tes unit sederhana. Namun, biasanya orang yang berpengalaman dengan suatu proyek tahu dengan tingkat kepastian yang masuk akal kategori apa yang cocok untuk berbagai bagian kode. Jika Anda tidak melakukan TDD, Anda setidaknya harus mencoba menulis tes yang paling berharga.

Baik itu tes unit, komponen, integrasi atau penerimaan, bagian yang penting adalah bahwa itu harus otomatis. Tidak memiliki tes otomatis adalah kesalahan fatal untuk semua jenis perangkat lunak, dari CRUD sederhana hingga perhitungan paling kompleks. Alasannya adalah bahwa menulis tes otomatis akan selalu lebih murah daripada kebutuhan berkesinambungan untuk menjalankan semua tes secara manual ketika Anda tidak melakukannya, berdasarkan pesanan besarnya. Setelah Anda menulisnya, Anda hanya perlu menekan tombol untuk melihat apakah mereka lulus atau gagal. Tes manual akan selalu memakan waktu lama untuk dijalankan, dan bergantung pada manusia (makhluk hidup yang bosan, mungkin kurang perhatian dan sebagainya) untuk dapat memeriksa apakah tes lulus atau gagal. Singkatnya, selalu menulis tes otomatis.

Sekarang, tentang alasan mengapa kolega Anda mungkin menentang melakukan segala jenis pengujian unit tanpa TDD: Mungkin karena lebih sulit untuk mempercayai tes yang ditulis setelah kode produksi. Dan jika Anda tidak bisa mempercayai tes otomatis Anda, mereka layak apa-apa . Setelah siklus TDD, Anda harus terlebih dahulu membuat tes gagal (untuk alasan yang tepat) untuk diizinkan menulis kode produksi agar lulus (dan tidak lebih). Proses ini pada dasarnya menguji pengujian Anda, sehingga Anda dapat memercayainya. Belum lagi fakta bahwa menulis tes sebelum kode aktual mendorong Anda untuk merancang unit dan komponen Anda agar lebih mudah diuji (tingkat tinggi decoupling, penerapan SRP, dll ...). Meskipun, tentu saja, melakukan TDD membutuhkan disiplin .

Alih-alih, jika Anda menulis semua kode produksi terlebih dahulu, saat Anda menulis tes untuk itu, Anda akan mengharapkan mereka lulus pada menjalankan pertama. Ini sangat bermasalah, karena Anda mungkin telah membuat tes yang mencakup 100% kode produksi Anda, tanpa menyatakan perilaku yang benar (bahkan mungkin tidak melakukan pernyataan apa pun! Saya pernah melihat ini terjadi ), karena Anda tidak dapat melihatnya gagal pertama untuk memeriksa apakah gagal karena alasan yang tepat. Dengan demikian, Anda mungkin memiliki kesalahan positif. Positif palsu pada akhirnya akan merusak kepercayaan pada test suite Anda, pada dasarnya memaksa orang untuk melakukan pengujian manual lagi, sehingga Anda memiliki biaya untuk kedua proses tersebut (menulis tes + tes manual).

Ini berarti Anda harus menemukan cara lain untuk menguji tes Anda , seperti TDD. Jadi Anda menggunakan debugging, mengomentari bagian dari kode produksi, dll., Agar dapat mempercayai pengujian. Masalahnya adalah bahwa proses "menguji tes Anda" jauh lebih lambat dengan cara ini. Menambahkan waktu ini ke waktu yang akan Anda habiskan untuk menjalankan tes ad-hoc secara manual (karena Anda tidak memiliki tes otomatis saat Anda mengode kode produksi), menurut pengalaman saya, menghasilkan keseluruhan proses yang jauh lebih lambat daripada berlatih. TDD "by the book" (Kent Beck - TDD dengan Contoh). Juga, saya bersedia bertaruh di sini dan mengatakan bahwa benar-benar "menguji tes Anda" setelah ditulis membutuhkan lebih banyak disiplin daripada TDD.

Jadi mungkin tim Anda dapat mempertimbangkan kembali "alasan bisnis dan non-bisnis" untuk tidak melakukan TDD. Dalam pengalaman saya, orang cenderung berpikir TDD lebih lambat dibandingkan dengan hanya menulis tes unit setelah kode selesai. Asumsi ini cacat, seperti yang Anda baca di atas.

Seringkali kualitas tes tergantung pada asalnya. Saya secara teratur bersalah karena tidak melakukan TDD 'nyata' - Saya menulis beberapa kode untuk membuktikan bahwa strategi yang ingin saya gunakan benar-benar berfungsi, kemudian membahas setiap kasus bahwa kode dimaksudkan untuk mendukung dengan tes sesudahnya. Biasanya unit kode adalah kelas, untuk memberi Anda gambaran umum tentang berapa banyak pekerjaan yang akan saya lakukan dengan senang hati tanpa cakupan tes - artinya, bukan jumlah yang besar. Apa artinya ini adalah bahwa makna semantik dari tes cocok dengan baik dengan sistem yang diuji dalam keadaan 'selesai' - karena saya menulis mereka mengetahui kasus-kasus apa yang dipenuhi oleh SUT dan bagaimana hal itu memenuhi mereka.

Sebaliknya, TDD dengan kebijakan refactoring agresif cenderung membuat tes usang setidaknya secepat Anda dapat menuliskannya sebagai antarmuka publik sistem yang sedang diuji perubahan. Secara pribadi saya menemukan beban kerja mental baik merancang unit fungsional aplikasi dan menjaga semantik tes yang menyelaraskannya menjadi terlalu tinggi untuk mempertahankan konsentrasi saya dan pemeliharaan tes sering tergelincir. Basis kode berakhir dengan tes berkeliaran yang tidak menguji sesuatu yang bernilai atau hanya salah. Jika Anda memiliki kedisiplinan dan kapasitas mental untuk tetap mengikuti test suite, tentu saja, praktikkan TDD seketat yang Anda inginkan. Saya tidak, jadi saya merasa kurang berhasil karena alasan itu.

Sebenarnya Paman Bob menyebutkan hal yang sangat menarik di salah satu video Clean Coders-nya. Dia mengatakan bahwa siklus Red-Green-Refactor dapat diterapkan dalam 2 cara.

1 adalah cara TDD konvensional. Tulis tes yang gagal lalu buat lulus ujian dan akhirnya refactor.

Cara kedua adalah dengan menulis kode produksi yang sangat kecil dan segera ikuti dengan unit test lalu refactor.

Idenya adalah untuk pergi dalam langkah - langkah yang sangat kecil . Tentu saja Anda kehilangan verifikasi dari kode produksi bahwa pengujian Anda berubah dari merah menjadi hijau, tetapi dalam beberapa kasus di mana saya bekerja sebagian besar dengan pengembang junior yang menolak bahkan untuk mencoba memahami TDD ternyata terbukti agak efektif.

Sekali lagi saya ulangi (dan ini ditekankan oleh Paman Bob) idenya adalah untuk pergi dalam langkah-langkah yang sangat kecil dan untuk segera menguji potongan kode produksi yang baru saja ditambahkan.