Kami menulis tes untuk memverifikasi kebenaran perilaku program.
Memverifikasi kebenaran perilaku program dengan memeriksa konten pernyataan keluaran menggunakan mata Anda adalah manual , atau lebih khusus, proses visual .
Anda bisa membantahnya
inspeksi visual bekerja , saya memeriksa bahwa kode melakukan apa yang seharusnya dilakukan, untuk skenario ini dan begitu saya bisa melihat itu benar kita baik untuk pergi.
Sekarang pertama-tama, itu bagus untuk Anda tertarik pada apakah atau tidak kode berfungsi dengan benar. Itu hal yang baik. Anda di depan kurva! Sayangnya, ada masalah dengan ini sebagai pendekatan.
Masalah pertama dengan inspeksi visual adalah Anda mengalami kecelakaan pengelasan yang buruk karena tidak dapat memeriksa lagi kebenaran kode Anda.
Masalah kedua adalah bahwa sepasang mata yang digunakan erat dengan otak pemilik mata. Jika pembuat kode juga memiliki mata yang digunakan dalam proses inspeksi visual, proses verifikasi kebenaran memiliki ketergantungan pada pengetahuan tentang program yang diinternalisasi dalam otak inspektur visual.
Sulit bagi sepasang mata baru untuk masuk dan memverifikasi kebenaran kode hanya karena mereka tidak bermitra dengan otak pembuat kode asli. Pemilik sepasang mata kedua harus berkomunikasi dengan pembuat kode yang asli agar dapat sepenuhnya memahami kode yang dimaksud. Percakapan sebagai sarana berbagi pengetahuan terkenal tidak bisa diandalkan. Suatu titik yang diperdebatkan jika Original Coder tidak tersedia untuk mata pasangan yang baru. Dalam hal itu, sepasang mata yang baru harus membaca kode asli.
Membaca kode orang lain yang tidak dicakup oleh tes unit lebih sulit daripada membaca kode yang memiliki tes unit terkait. Paling-paling membaca kode orang lain adalah pekerjaan yang sulit, paling buruk ini adalah tugas yang paling bombastis dalam rekayasa perangkat lunak. Ada alasan bahwa pengusaha, ketika mengiklankan lowongan pekerjaan, menekankan bahwa suatu proyek adalah bidang baru (atau baru). Menulis kode dari awal lebih mudah daripada memodifikasi kode yang ada dan dengan demikian membuat pekerjaan yang diiklankan tampak lebih menarik bagi karyawan potensial.
Dengan pengujian unit kami membagi kode menjadi bagian-bagian komponennya. Untuk setiap komponen kami kemudian menetapkan kios kami yang menyatakan bagaimana program harus bersikap . Setiap tes unit menceritakan tentang bagaimana bagian program itu harus bertindak dalam skenario tertentu. Setiap pengujian unit seperti klausa dalam kontrak yang menjelaskan apa yang harus terjadi dari sudut pandang kode klien.
Ini kemudian berarti bahwa sepasang mata baru memiliki dua untaian dokumentasi langsung dan akurat pada kode yang dimaksud.
Pertama, mereka memiliki kode itu sendiri, implementasi, bagaimana kode itu dilakukan ; kedua mereka memiliki semua pengetahuan yang dijelaskan oleh pembuat kode asli dalam seperangkat pernyataan formal yang menceritakan kisah bagaimana kode ini seharusnya berperilaku.
Tes unit menangkap dan secara formal menggambarkan pengetahuan yang dimiliki penulis asli ketika mereka mengimplementasikan kelas. Mereka memberikan deskripsi tentang bagaimana kelas itu berperilaku ketika digunakan oleh klien.
Anda benar untuk mempertanyakan kegunaan melakukan ini karena dimungkinkan untuk menulis unit test yang tidak berguna, tidak mencakup semua kode yang dimaksud, menjadi basi atau ketinggalan zaman dan sebagainya. Bagaimana kita memastikan bahwa unit test tidak hanya meniru tetapi juga memperbaiki proses seorang penulis yang berpengetahuan luas dan teliti memeriksa laporan output kode mereka saat runtime? Tulis tes unit terlebih dahulu kemudian tulis kode untuk lulus tes. Ketika Anda selesai, biarkan komputer menjalankan tes, mereka cepat mereka hebat dalam melakukan tugas yang berulang-ulang mereka cocok untuk pekerjaan itu.
Pastikan kualitas pengujian dengan meninjau mereka setiap kali Anda menyentuh kode yang mereka uji dan menjalankan tes untuk setiap build. Jika tes gagal, segera perbaiki.
Kami mengotomatiskan proses menjalankan tes sehingga mereka dijalankan setiap kali kami membangun proyek. Kami juga mengotomatiskan pembuatan laporan cakupan kode yang merinci persentase kode yang dicakup dan dilaksanakan oleh pengujian. Kami berusaha keras untuk mendapatkan persentase tinggi. Beberapa perusahaan akan mencegah perubahan kode dari diperiksa ke kontrol kode sumber jika mereka tidak memiliki tes unit yang cukup tertulis untuk menggambarkan perubahan perilaku pada kode. Biasanya sepasang mata kedua akan meninjau perubahan kode bersama dengan penulis perubahan. Peninjau akan melalui perubahan memastikan bahwa perubahan dapat dipahami dan dicakup oleh tes. Jadi proses peninjauan adalah manual, tetapi ketika tes (unit dan tes integrasi dan mungkin tes penerimaan pengguna) lulus proses review manual ini menjadi bagian dari proses build otomatis. Ini dijalankan setiap kali perubahan dicentang. Aintegrasi berkelanjutan server melakukan tugas ini sebagai bagian dari proses pembangunan.
Pengujian yang dijalankan secara otomatis, menjaga integritas perilaku kode dan membantu mencegah perubahan di masa mendatang pada basis kode dari memecahkan kode .
Akhirnya, memberikan tes memungkinkan Anda untuk secara agresif memasukkan kembali kode faktor karena Anda dapat membuat perbaikan kode besar aman karena mengetahui bahwa perubahan Anda tidak merusak tes yang ada.
Ada peringatan untuk Pengembangan Test Driven dan itu adalah bahwa Anda harus menulis kode dengan mata agar dapat diuji. Ini melibatkan pengkodean ke antarmuka dan menggunakan teknik seperti Dependency Injection untuk instantiate objek yang berkolaborasi. Lihatlah karya Kent Beck yang menggambarkan TDD dengan sangat baik. Cari kode untuk antarmuka dan belajarpola desain
