Apa itu TDD dan pengujian unit [terjemahan]

Artikel ini merupakan adaptasi satu bab dari buku Panduan Karir Perangkat Lunak Lengkap. Penulisnya, John Sonmez, menulisnya dan memposting beberapa bab di situsnya.

Glosarium singkat untuk pemula

Pengujian unit atau pengujian unit adalah proses dalam pemrograman yang memungkinkan Anda memeriksa kebenaran masing-masing modul kode sumber program. Idenya adalah untuk menulis tes untuk setiap fungsi atau metode non-sepele. Pengujian regresi adalah nama umum untuk semua jenis pengujian perangkat lunak yang bertujuan mendeteksi kesalahan di area kode sumber yang sudah diuji. Kesalahan seperti itu - ketika, setelah melakukan perubahan pada program, sesuatu yang seharusnya terus berfungsi berhenti bekerja - disebut kesalahan regresi. Hasil merah, gagal – kegagalan tes. Perbedaan antara hasil yang diharapkan dan hasil sebenarnya. Hasil hijau, lulus - hasil tes positif. Hasil sebenarnya tidak berbeda dengan apa yang diperoleh. *** Saya memiliki hubungan yang sangat beragam dengan Test Driven Development (TDD) dan pengujian unit, berubah dari cinta menjadi benci dan kembali lagi. Saya adalah penggemar berat dan pada saat yang sama skeptis terhadap penggunaan “praktik terbaik” ini dan lainnya. Alasan sikap saya didasarkan pada fakta bahwa masalah serius telah muncul dalam proses pengembangan perangkat lunak: pengembang, dan terkadang manajer, menggunakan alat dan metodologi tertentu hanya karena alat dan metodologi tersebut termasuk dalam “praktik terbaik”. Alasan sebenarnya penggunaannya masih belum jelas. Suatu hari saya mulai mengerjakan proyek tertentu, dan dalam prosesnya saya diberitahu bahwa kami akan memodifikasi kode yang dicakup oleh sejumlah besar unit test. Tidak main-main, jumlahnya ada sekitar 3000. Ini biasanya merupakan pertanda baik, pertanda bahwa pengembang menggunakan metodologi tingkat lanjut. Kode dengan pendekatan ini paling sering terstruktur, dan didasarkan pada arsitektur yang dipikirkan dengan matang. Singkat kata, kehadiran tes membuat saya senang, setidaknya karena itu berarti mempermudah pekerjaan saya sebagai mentor programmer. Karena kami sudah melakukan pengujian unit, yang harus saya lakukan hanyalah menghubungkan tim pengembangan untuk mendukungnya dan mulai menulis kode kami sendiri. Saya membuka IDE (lingkungan pengembangan terintegrasi) dan memuat proyek. Itu adalah proyek besar! Saya menemukan folder berlabel "unit test". “Bagus,” pikirku. - Ayo luncurkan dan lihat apa yang terjadi. Hanya butuh beberapa menit, dan yang mengejutkan saya, semua tes lulus, semuanya berwarna hijau ( "hijau" adalah hasil tes yang positif. Sinyal bahwa kode berfungsi seperti yang diharapkan. Merah menunjukkan "gagal" atau gagal, lalu ada kasus ketika kode tidak berfungsi dengan benar - catatan penerjemah ). Mereka semua lulus ujian. Pada saat itu, rasa skeptis dalam diri saya terbangun. Kok bisa, tiga ribu unit test, dan mereka melakukan semuanya sekaligus - dan memberikan hasil yang positif? Dalam praktik panjang saya, saya tidak dapat mengingat kapan saya mulai mengerjakan sebuah proyek tanpa satu pun pengujian unit negatif dalam kodenya. Apa yang harus dilakukan? Periksa secara manual! ChY memilih satu tes acak, bukan yang paling terbuka, tapi langsung jelas apa yang dia periksa. Namun saat mengerjakannya, saya melihat sesuatu yang tidak masuk akal: tes tersebut tidak berisi perbandingan apa pun dengan hasil yang diharapkan (menegaskan)! Artinya, kenyataannya tidak ada yang diperiksa sama sekali ! Ada langkah-langkah tertentu dalam tes, itu dilakukan, tetapi di akhir tes, di mana dia harus membandingkan hasil sebenarnya dan hasil yang diharapkan, tidak ada pemeriksaan. "Tes" itu tidak menguji apa pun. Saya membuka tes lain. Lebih baik lagi: operator perbandingan dengan hasilnya telah dikomentari. Cemerlang! Ini adalah cara yang bagus untuk melakukan tes lulus, cukup beri komentar pada kode yang menyebabkannya gagal. Saya memeriksa tes lain, lalu tes lainnya... Tak satu pun dari mereka memeriksa apa pun. Tiga ribu tes, dan semuanya sama sekali tidak berguna. Ada perbedaan besar antara menulis pengujian unit dan memahami pengujian unit dan pengembangan berbasis pengujian (TDD).

Apa itu pengujian unit?

Ide dasar pengujian unit adalah menulis pengujian yang menguji “unit” terkecil dari kode. Tes unit biasanya ditulis dalam bahasa pemrograman yang sama dengan kode sumber aplikasi. Mereka dibuat langsung untuk menguji kode ini. Artinya, pengujian unit adalah kode yang memeriksa kebenaran kode lainnya. Saya menggunakan kata "tes" secara bebas dalam konteksnya, karena pengujian unit dalam beberapa hal bukanlah pengujian. Mereka tidak mengalami apa pun. Maksud saya adalah ketika Anda menjalankan pengujian unit, Anda biasanya tidak menemukan bahwa beberapa kode tidak berfungsi. Anda menemukan hal ini saat menulis tes, karena Anda akan mengubah kode hingga tes berubah menjadi hijau. Ya, kodenya mungkin berubah nanti dan pengujian Anda mungkin gagal. Jadi dalam pengertian ini, pengujian unit adalah pengujian regresi. Pengujian unit tidak seperti pengujian biasa di mana Anda memiliki beberapa langkah yang akan Anda ikuti dan Anda melihat apakah perangkat lunak berfungsi dengan benar atau tidak. Selama proses penulisan pengujian unit, Anda mengetahui apakah kode tersebut berfungsi sebagaimana mestinya atau tidak, dan Anda akan mengubah kode tersebut hingga pengujian tersebut berhasil. Mengapa tidak menulis unit test dan memeriksa apakah berhasil? Jika Anda memikirkannya seperti ini, maka pengujian unit berubah menjadi semacam persyaratan mutlak untuk modul kode tertentu pada tingkat yang sangat rendah. Anda dapat menganggap pengujian unit sebagai spesifikasi mutlak . Pengujian unit menentukan bahwa dalam kondisi ini, dengan kumpulan masukan tertentu, terdapat keluaran yang harus Anda peroleh dari unit kode ini. Pengujian unit yang sebenarnya mengidentifikasi unit kode terkecil yang koheren, yang dalam sebagian besar bahasa pemrograman - setidaknya yang berorientasi objek - adalah sebuah kelas.

Apa yang terkadang disebut pengujian unit?

Pengujian unit sering disalahartikan dengan pengujian integrasi. Beberapa "pengujian unit" menguji lebih dari satu kelas atau menguji unit kode yang besar. Banyak pengembang mengklaim bahwa mereka menulis pengujian unit padahal sebenarnya mereka menulis pengujian whitebox tingkat rendah. Jangan berdebat dengan orang-orang ini. Ketahuilah bahwa mereka benar-benar menulis pengujian integrasi, dan pengujian unit yang sebenarnya menguji unit kode terkecil secara terpisah dari bagian lain. Hal lain yang sering disebut pengujian unit adalah pengujian unit tanpa memeriksa nilai yang diharapkan. Dengan kata lain, pengujian unit yang sebenarnya tidak menguji apa pun. Tes apa pun, baik yang disatukan atau tidak, harus menyertakan semacam verifikasi - kami menyebutnya pemeriksaan hasil aktual terhadap hasil yang diharapkan. Rekonsiliasi inilah yang menentukan lulus atau gagalnya ujian tersebut. Ujian yang selalu lulus tidak ada gunanya. Ujian yang selalu gagal tidak ada gunanya.

Nilai Pengujian Unit

Mengapa saya penggemar pengujian unit? Mengapa berbahaya untuk menyebut pengujian umum, yang melibatkan pengujian bukan pada blok terkecil yang diisolasi dari kode lain, tetapi bagian kode yang lebih besar, “pengujian unit”? Apa masalahnya jika beberapa pengujian saya tidak membandingkan hasil yang diterima dan yang diharapkan? Setidaknya mereka mengeksekusi kodenya. Saya akan mencoba menjelaskannya. Ada dua alasan utama untuk melakukan pengujian unit. Yang pertama adalah memperbaiki desain kode. Ingat bagaimana saya mengatakan bahwa pengujian unit sebenarnya bukan pengujian? Saat Anda menulis pengujian unit yang tepat, Anda memaksakan diri untuk mengisolasi unit kode terkecil. Upaya ini akan membawa Anda menemukan masalah pada struktur kode itu sendiri. Anda mungkin merasa sangat sulit untuk mengisolasi kelas pengujian dan tidak menyertakan dependensinya, dan ini mungkin membuat Anda menyadari bahwa kode Anda terlalu erat digabungkan. Anda mungkin menemukan bahwa fungsionalitas inti yang Anda coba uji mencakup beberapa modul, sehingga membuat Anda yakin bahwa kode Anda tidak cukup koheren. Saat Anda duduk untuk menulis pengujian unit, Anda mungkin tiba-tiba menemukan (dan percayalah, itu terjadi!) bahwa Anda tidak tahu apa yang seharusnya dilakukan kode tersebut. Oleh karena itu, Anda tidak akan dapat menulis pengujian unit untuk itu. Dan tentu saja, Anda mungkin menemukan bug nyata dalam implementasi kode, karena pengujian unit memaksa Anda untuk berpikir di luar kebiasaan dan menguji rangkaian masukan berbeda yang mungkin belum Anda pertimbangkan. Jika Anda benar-benar mematuhi aturan "uji unit kode terkecil secara terpisah dari yang lain" saat membuat pengujian unit, Anda pasti akan menemukan segala macam masalah dengan kode tersebut dan desain modul tersebut. Dalam siklus hidup pengembangan perangkat lunak, pengujian unit lebih merupakan aktivitas evaluasi daripada aktivitas pengujian. Tujuan utama kedua dari pengujian unit adalah untuk membuat serangkaian pengujian regresi otomatis yang dapat bertindak sebagai spesifikasi perilaku perangkat lunak tingkat rendah. Apa artinya? Saat Anda menguleni adonan, Anda tidak merusaknya. Dari sudut pandang ini, pengujian unit adalah pengujian, lebih khusus lagi pengujian regresi. Namun, tujuan pengujian unit bukan sekadar membuat pengujian regresi. Dalam praktiknya, pengujian unit jarang menangkap regresi, karena perubahan pada unit kode yang Anda uji hampir selalu berisi perubahan pada pengujian unit itu sendiri. Pengujian regresi jauh lebih efektif pada level yang lebih tinggi, ketika kode diuji sebagai “kotak hitam”, karena pada level ini struktur internal kode dapat diubah, sedangkan perilaku eksternal diharapkan tetap sama. Pengujian unit pada gilirannya memeriksa struktur internal, sehingga ketika struktur tersebut berubah, pengujian unit tidak gagal. Mereka menjadi tidak dapat digunakan dan sekarang perlu diubah, dibuang atau ditulis ulang. Anda sekarang tahu lebih banyak tentang tujuan sebenarnya dari pengujian unit dibandingkan banyak pengembang perangkat lunak veteran.

Apa itu Pengembangan Berbasis Tes (TDD)?

Dalam proses pengembangan perangkat lunak, spesifikasi yang baik bernilai emas. Pendekatan TDD adalah sebelum Anda menulis kode apa pun, Anda terlebih dahulu menulis tes yang akan berfungsi sebagai spesifikasi, yaitu menentukan apa yang harus dilakukan kode tersebut. Ini adalah konsep pengembangan perangkat lunak yang sangat kuat, namun sering disalahgunakan. Biasanya, pengembangan berbasis pengujian berarti menggunakan pengujian unit untuk memandu pembuatan kode aplikasi. Namun nyatanya, pendekatan ini bisa diterapkan di tingkat mana pun. Namun, dalam artikel ini kami akan berasumsi bahwa kami menggunakan pengujian unit untuk aplikasi kami. Pendekatan TDD mengubah segalanya, dan alih-alih menulis kode terlebih dahulu lalu menulis pengujian unit untuk menguji kode tersebut, Anda menulis pengujian unit terlebih dahulu dan kemudian menulis kode untuk menjadikan pengujian tersebut ramah lingkungan. Dengan cara ini, pengujian unit “mendorong” pengembangan kode. Proses ini diulangi lagi dan lagi. Anda menulis tes lain yang mendefinisikan lebih banyak fungsionalitas dari apa yang harus dilakukan kode. Anda kemudian menulis dan memodifikasi kode untuk memastikan bahwa pengujian berhasil diselesaikan. Setelah Anda mendapatkan hasil berwarna hijau, Anda mulai memfaktorkan ulang kode, yaitu memfaktorkan ulang atau membersihkannya agar lebih ringkas. Rangkaian proses ini sering disebut "Merah-Hijau-Refactoring" karena pertama-tama pengujian unit gagal (merah), kemudian kode ditulis untuk beradaptasi dengan pengujian, memastikan keberhasilannya (hijau), dan terakhir kode tersebut dioptimalkan ( pemfaktoran ulang). .

Apa tujuan dari TDD?

Pengembangan berbasis pengujian (TDD), seperti pengujian unit, dapat digunakan secara tidak benar. Sangat mudah untuk menyebut apa yang Anda lakukan "TDD" dan bahkan mengikuti latihannya tanpa memahami mengapa Anda melakukannya seperti itu. Nilai TDD yang terbesar adalah pengujian dilakukan untuk menghasilkan spesifikasi kualitas. TDD pada dasarnya adalah praktik penulisan spesifikasi tepat yang dapat diperiksa secara otomatis sebelum pengkodean ditulis. Tes adalah spesifikasi terbaik karena tidak berbohong. Mereka tidak akan memberi tahu Anda setelah dua minggu tersiksa dengan kode “bukan itu yang saya maksudkan sama sekali.” Tes, jika ditulis dengan benar, akan lulus atau gagal. Tes dengan jelas menunjukkan apa yang harus terjadi dalam keadaan tertentu. Oleh karena itu, tujuan TDD adalah memberi kita pemahaman lengkap tentang apa yang perlu kita terapkan sebelum kita mulai menerapkannya. Jika Anda baru memulai dengan TDD dan tidak tahu tes apa yang seharusnya diuji, maka Anda perlu mengajukan lebih banyak pertanyaan. Peran penting lainnya dari TDD adalah untuk melestarikan dan mengoptimalkan kode. Pemeliharaan kode itu mahal. Saya sering bercanda bahwa programmer terbaik adalah orang yang menulis kode terpendek yang memecahkan suatu masalah. Atau bahkan orang yang membuktikan bahwa masalah ini tidak perlu diselesaikan, dan dengan demikian menghapus kode sepenuhnya, karena pemrogram inilah yang menemukan cara yang tepat untuk mengurangi jumlah kesalahan dan mengurangi biaya pemeliharaan aplikasi. Dengan menggunakan TDD, Anda dapat benar-benar yakin bahwa Anda tidak sedang menulis kode yang tidak perlu, karena Anda hanya akan menulis kode untuk lulus tes. Ada prinsip pengembangan perangkat lunak yang disebut YAGNI (Anda tidak memerlukannya). TDD mencegah YAGNI.

Alur Kerja Pengembangan Berbasis Tes (TDD).

Sulit untuk memahami arti TDD dari sudut pandang akademis semata. Jadi mari kita lihat contoh sesi TDD. Bayangkan duduk di depan meja Anda dan dengan cepat membuat sketsa apa yang menurut Anda akan menjadi desain tingkat tinggi untuk fitur yang memungkinkan pengguna masuk ke aplikasi dan mengubah kata sandinya jika mereka lupa. Anda memutuskan bahwa Anda akan memulai dengan implementasi pertama dari fungsi login, membuat kelas yang akan menangani semua logika untuk proses login. Anda membuka editor favorit Anda dan membuat pengujian unit yang disebut "Login kosong mencegah pengguna masuk." Anda menulis kode pengujian unit yang pertama kali membuat instance kelas Login (yang belum Anda buat). Anda kemudian menulis kode untuk memanggil metode di kelas Login yang meneruskan nama pengguna dan kata sandi kosong. Terakhir, Anda menulis cek terhadap hasil yang diharapkan, memeriksa bahwa pengguna dengan login kosong sebenarnya tidak login. Anda mencoba menjalankan pengujian, tetapi pengujian tersebut tidak dapat dikompilasi karena Anda tidak memiliki kelas Login. Anda memperbaiki situasi ini dan membuat kelas Login bersama dengan metode di kelas itu untuk login dan metode lain untuk memeriksa status pengguna guna melihat apakah mereka sudah login. Sejauh ini Anda belum mengimplementasikan fungsionalitas kelas ini dan metode yang kami perlukan. Anda menjalankan tes pada saat ini. Sekarang sudah dikompilasi, tetapi langsung gagal. Sekarang Anda kembali ke kode dan mengimplementasikan fungsionalitas untuk lulus ujian. Dalam kasus kita, ini berarti kita akan mendapatkan hasil: “pengguna belum masuk.” Anda menjalankan pengujian lagi dan sekarang pengujian tersebut berhasil. Mari kita lanjutkan ke tes berikutnya. Sekarang bayangkan Anda perlu menulis tes yang disebut "Pengguna masuk jika mereka memasukkan nama pengguna dan kata sandi yang valid." Anda menulis pengujian unit yang membuat instance kelas Login dan mencoba masuk dengan nama pengguna dan kata sandi. Dalam pengujian unit, Anda menulis pernyataan bahwa kelas Login harus menjawab ya untuk pertanyaan apakah pengguna sudah login. Anda menjalankan tes baru ini dan tentu saja gagal karena kelas Login Anda selalu mengembalikan bahwa pengguna tidak login. Anda kembali ke kelas Login dan menerapkan beberapa kode untuk memverifikasi bahwa pengguna telah login. Dalam hal ini, Anda harus memikirkan cara mengisolasi modul ini. Untuk saat ini, cara termudah untuk melakukan ini adalah dengan melakukan hardcode nama pengguna dan kata sandi yang Anda gunakan dalam pengujian, dan jika cocok, kembalikan hasil "pengguna sudah masuk". Anda melakukan perubahan ini, menjalankan kedua pengujian, dan keduanya lulus. Mari beralih ke langkah terakhir: Anda melihat kode yang dihasilkan, dan mencari cara untuk mengatur ulang dan menyederhanakannya. Jadi algoritma TDDnya adalah:

1. Membuat tes.
2. Kami menulis kode untuk tes ini.
3. Memfaktorkan ulang kodenya.

kesimpulan

Itu saja yang ingin saya sampaikan kepada Anda tentang pengujian unit dan TDD pada tahap ini. Faktanya, ada banyak kesulitan yang terkait dengan upaya mengisolasi modul kode, karena kode tersebut bisa sangat rumit dan membingungkan. Sangat sedikit kelas yang berada dalam isolasi total. Sebaliknya, mereka memiliki ketergantungan, dan ketergantungan tersebut memiliki ketergantungan, dan seterusnya. Untuk menghadapi situasi seperti itu, veteran TDD menggunakan tiruan, yang membantu mengisolasi masing-masing kelas dengan mengganti objek dalam modul dependen. Artikel ini hanyalah gambaran umum dan pengenalan yang disederhanakan tentang pengujian unit dan TDD, kami tidak akan membahas secara detail tentang modul dummy dan teknik TDD lainnya. Idenya adalah untuk memberi Anda konsep dan prinsip dasar TDD dan pengujian unit yang semoga Anda miliki sekarang. Asli - https://simpleprogrammer.com/2017/01/30/tdd-unit-testing/