Apa yang dimaksud dengan pengembangan berbasis pengujian (TDD)?

Pengembang menulis kode yang cukup untuk melewati setiap pengujian, kemudian pengujian dan kode tersebut disempurnakan sebelum beralih ke pengujian baru dan kemudian fitur baru.

Pengembangan berbasis pengujian pada dasarnya memaksa pengembang untuk memperlambat, memvalidasi, dan menyempurnakan kode mereka dalam siklus evaluasi yang lebih pendek. Meskipun tidak diperlukan, tim DevOps mendorong pembuat kode, dari pemula hingga profesional berpengalaman, untuk menggunakan TDD di berbagai bahasa pemrograman. Misalnya, Java, Python, dan sebagainya, antarmuka pemrograman aplikasi (application programming interface, API) dan aplikasi program.

Pemrograman dengan metode ini memperkuat hubungan antara pengodean, pengujian (dalam bentuk pengujian tingkat unit otomatis), dan desain kode. Meskipun pengembangan berbasis pengujian dapat meningkatkan waktu pengembangan awal, metode ini telah terbukti dapat meningkatkan fungsionalitas kode dan ketangkasan, serta menghemat waktu secara keseluruhan.

Dengan segera mengidentifikasi dan mengatasi kesalahan apa pun, pengembang yang menggunakan TDD dapat mencegah masalah kecil berkembang menjadi masalah yang lebih besar. Pengembangan berbasis pengujian memaksa pengembang untuk memvalidasi dan menyempurnakan kode selama proses pengembangan, sehingga menyederhanakan pemeriksaan kualitas akhir dan perbaikan. 

Kerangka kerja pengujian alternatif mencakup penulisan kode produksi sebelum semua pengujian otomatis ditulis, atau penulisan seluruh rangkaian pengujian sebelum kode produksi ditulis. Metode ini, meskipun belum tentu tidak efektif, telah terbukti meningkatkan waktu debugging yang diperlukan, terutama pada proyek yang lebih besar dan lebih kompleks.

Meskipun pengembangan berbasis pengujian umumnya digunakan untuk pembuatan kode produksi baru, metode ini juga sering digunakan untuk meningkatkan debugging kode lama yang dikembangkan dengan teknik yang lebih lama atau teknik lainnya. 

Pengembangan berbasis pengujian memutarbalikkan proses pengembangan tradisional dengan menempatkan pengujian sebelum pengembangan. Sebagai pendekatan berulang, pengembangan berbasis pengujian meningkatkan kualitas dan keterbacaan kode dengan mendorong alur kerja yang dapat diuji dan menghasilkan kode berkualitas tinggi di tingkat unit. Ketika menerapkan pengujian unit, pengembang berfokus pada sebagian kecil logika, misalnya sebuah algoritma. Menulis kode secara khusus agar lulus pengujian tidak hanya menghasilkan kode yang lebih bersih dan lebih andal, tetapi juga membantu meningkatkan dokumentasi. 

Ada dua tingkat utama pada pengembangan berbasis pengujian.

Pada TDD Penerimaan (acceptance test-driven development, ATDD), yang terkadang disebut sebagai Pengembangan Berbasis Perilaku (Behavior-Driven Development, BDD), pemrogram menulis satu pengujian penerimaan dan kemudian kode baru yang cukup untuk lulus pengujian. Pengujian penerimaan terkadang disebut sebagai pengujian pelanggan atau pengujian penerimaan pelanggan.

Secara umum, ini dapat dipahami sebagai contoh pengujian yang diperlukan untuk fungsionalitas minimum sebagaimana diuraikan oleh pemangku kepentingan produk. ATDD berupaya mengidentifikasi persyaratan yang terperinci dan dapat dieksekusi. Pengujian penerimaan dapat dilakukan dengan menggunakan berbagai alat pengujian, seperti Fitnesse atau RSpec.

Terkadang cukup disebut sebagai TDD, TDD pengembang mengharuskan pembuat kode untuk menulis satu pengujian guna mengevaluasi solusinya sendiri untuk pengujian ATDD. TDD pengembang menggunakan alat otomatisasi pengujian, seperti JUnit atau VBUNit. 

Ketika menggunakan strategi pengembangan berbasis pengujian, pembuat kode pertama-tama menulis pengujian untuk memeriksa setiap elemen atau fungsi bagian perangkat lunak sebelum menulis kode yang cukup untuk lulus pengujian tersebut. Setelah selesai, perangkat lunak diuji kembali. Jika lulus, kode akan disempurnakan (dalam proses yang dikenal sebagai pemfaktoran ulang atau refactoring) agar hanya menyertakan elemen-elemen yang penting. Pengembang kemudian mengulangi proses ini untuk setiap fungsi perangkat lunak berikutnya. 

Proses pengembangan berbasis pengujian dibagi menjadi lima langkah terpisah:

1. Sebelum menulis kode untuk fungsi perangkat lunak tertentu, pengembang terlebih dahulu menulis satu pengujian unit untuk fungsi tersebut.
2. Pengembang kemudian menjalankan pengujian, yang seharusnya gagal karena fungsi kode belum ditulis. Langkah ini penting untuk memastikan bahwa pengujian itu sendiri berfungsi dan tidak menampilkan hasil positif palsu. Jika kode lulus, ini menunjukkan bahwa pengujian perlu ditulis ulang.
3. Ketika program gagal dalam pengujian, pengembang hanya menulis kode perangkat lunak tambahan yang cukup untuk lulus pengujian. 
4. Ketika kode berhasil lulus pengujian, baik pengujian maupun kode akan difaktorkan ulang untuk disederhanakan dan untuk menghilangkan kode yang tidak perlu. 
5. Ketika perangkat lunak yang telah difaktorkan ulang secara memadai berhasil lulus pengujian pemfaktoran ulang, pengembang akan beralih ke fungsi perangkat lunak yang diinginkan berikutnya. Penguji kemudian menulis dan menjalankan pengujian untuk setiap fitur baru. 

Sederhananya, proses pengembangan berbasis pengujian mengikuti siklus yang berulang, yang disebut sebagai siklus merah-hijau-faktor ulang (red-green-refactor). Tahapan siklusnya adalah:

• Merah: Menulis pengujian yang gagal untuk perilaku perangkat lunak yang diinginkan. 

• Hijau: Menulis tambahan yang cukup untuk lulus pengujian.

• Faktor ulang: Menyempurnakan kode untuk memenuhi standar kesederhanaan sebanyak mungkin sekaligus tetap lulus pengujian.

Meskipun asal-usul spesifik pengembangan berbasis pengujian tidak diketahui, konsep menulis pengujian terlebih dahulu, lalu dilanjutkan dengan kode produksi, bukanlah praktik yang umum hingga pertengahan tahun 1990-an. Sebelum itu, kerangka kerja pengujian memisahkan pengembang dari pengujian basis kode mereka sendiri. Namun, seiring dengan perkembangan rekayasa perangkat lunak, tim DevOps membutuhkan metodologi yang lebih cepat dan lebih fleksibel untuk memenuhi permintaan pemangku kepentingan, terutama ketika berhadapan dengan kebutuhan pemangku kepentingan yang berubah dengan cepat. 

Pengembangan berbasis pengujian dikembangkan dari dan bersama dengan berbagai kerangka kerja pengujian baru, serta telah diadopsi sebagai komponen modular dalam berbagai kerangka kerja lainnya. Yang paling menonjol, TDD disertakan dalam konsep Extreme Programming (XP), yakni kerangka kerja pengembangan perangkat lunak yang dikembangkan untuk meningkatkan kualitas perangkat lunak dan kualitas hidup pengembang.

Insinyur perangkat lunak Kent Beck, yang merupakan tokoh penting dalam komunitas Tangkas dan pencipta Extreme Programming, dikenal sebagai sosok yang “menemukan kembali” pengembangan berbasis pengujian. Menurut pernyataan Beck: 

“Deskripsi awal TDD tertulis di sebuah buku lawas tentang pemrograman. Dikatakan bahwa kita perlu mengambil pita input, mengetikkan secara manual pita output yang kita harapkan, lalu memprogram hingga pita output sebenarnya itu sesuai dengan output yang diharapkan. Setelah menulis kerangka kerja xUnit pertama di Smalltalk, saya ingat pernah membaca hal ini dan mencobanya. Itulah asal mula TDD bagi saya. Ketika menjelaskan TDD kepada pemrogram yang lebih senior, saya sering mendengar komentar, " Tentu saja. Bagaimana lagi kita bisa memprogram?" Oleh karena itu, saya menyebut diri sebagai orang yang "menemukan kembali" TDD.” 

Tanggal-tanggal penting dalam evolusi pengembangan berbasis pengujian meliputi:

• 1976: Glenford Myers menerbitkan Software Reliability, yang memuat pendapatnya bahwa “pengembang tidak boleh menguji kodenya sendiri”. Meskipun Myers mungkin bukan pencetus konsep ini, karyanya mendukung gagasan umum yang akan terus berlanjut selama bertahun-tahun mendatang. 

• 1990: Pada awal dekade ini, teknik “kotak hitam” mendominasi pengujian perangkat lunak. Dalam kerangka kerja pengujian semacam ini, penguji memperlakukan perangkat lunak seolah-olah sebuah “kotak hitam”, yang tidak dapat ditembus dan tidak dapat diketahui. Pengujian kotak hitam menggunakan penguji yang, secara kritis, tidak memiliki pengetahuan tentang cara kerja internal perangkat lunak yang terkait. 

• 1994: Kent Beck mengembangkan SUnit, kerangka kerja pengujian Smalltalk, yang menjadi dasar untuk pendekatan yang mengutamakan pengujian (test-first approach) untuk pengoptimalan basis kode. 

• 1999–2002: Seiring maraknya gerakan pengembangan tangkas, Kent Beck mengembangkan konsep Extreme Programming, dengan mengodifikasi pengembangan berbasis pengujian dan memperkenalkan konsep penting objek tiruan. TDD menggunakan objek tiruan untuk menyimulasikan perilaku dependensi nyata (misalnya, database, layanan eksternal, dan sebagainya) selama pengujian. Metode ini membantu pengembang memfokuskan kode pengujian pada objek tiruan yang dapat dipelihara dan dapat diverifikasi agar bekerja secara akurat. Pengujian gagal yang menggunakan objek tiruan dapat menghilangkan dependensi yang berpotensi salah konfigurasi sebagai sumber kegagalan. 

• 2003: Kent Beck menerbitkan Test Driven Development: By Example, yang mempopulerkan praktik tersebut di kalangan komunitas pengembangan yang lebih luas serta mempromosikan pengujian berbasis pengembang. 

Sebagai komponen dari Extreme Programming, pengembangan berbasis pengujian telah terbukti bermanfaat tidak hanya untuk membuat kode yang lebih baik, tetapi juga untuk meningkatkan kualitas pembuat kode. Dengan TDD, pembuat kode dapat memperoleh insight yang lebih baik tentang proyek mereka dan membantu mendorong desain program. Dengan memusatkan contoh pengujian sebelum setiap fitur diimplementasikan, pengembang harus memvisualisasikan bagaimana sebuah fungsi akan digunakan oleh klien atau pengguna. Pendekatan ini memosisikan antarmuka produk sebelum implementasi dan membantu pengembang membuat aplikasi yang lebih berfokus pada pengguna. 

Beberapa manfaat lain dari pengembangan berbasis pengujian meliputi:

• Cakupan pengujian yang komprehensif: TDD terkadang disebut sebagai alat spesifikasi atau dokumentasi, karena praktik ini memastikan bahwa semua kode dicakup oleh setidaknya satu pengujian. 

• Meningkatkan dokumentasi: Untuk alasan yang sama bahwa TDD menyediakan cakupan yang komprehensif, TDD juga menyediakan dokumentasi dan spesifikasi yang andal. Sistem ini membantu pengembang, manajer proyek, dan pemangku kepentingan lainnya memvalidasi fitur dan persyaratan kode serta menegakkan ketertiban melalui siklus proses proyek. 

• Meningkatkan kepercayaan diri: Pengembang dan tim DevOps yang menggunakan TDD mendapatkan kepercayaan diri yang lebih besar, tidak hanya untuk kode, tetapi juga terkait pengujian mereka. 

• Memfasilitasi integrasi berkelanjutan: TDD sangat cocok untuk praktik integrasi berkelanjutan, di mana kode langsung terus diperbarui dengan fitur dan patch baru. 

• Mengurangi debugging: TDD melakukan pengujian di awal dalam proses pengembangan, sehingga mengurangi kebutuhan akan debugging yang ekstensif di bagian akhir pengembangan. 

• Memperjelas detail kebutuhan: TDD membantu pengembang membangun pemahaman yang jelas tentang setiap kebutuhan program tertentu sebelum mulai bekerja. 

• Meningkatkan produktivitas: TDD kerap dikaitkan dengan peningkatan produktivitas di antara pengembang karena proses ini membantu menguraikan proyek-proyek besar menjadi langkah-langkah yang lebih kecil dan lebih mudah dicapai. 

• Meningkatkan kepraktisan desain: Langkah ketiga yang penting dalam siklus TDD hijau-merah-faktor ulang mengharuskan pengembang untuk melakukan pemfaktoran ulang dan menyederhanakan kode. Praktik ini meningkatkan kepraktisan dan kualitas desain secara umum. 

• Memperkuat model mental: Dengan memeriksa dan mengintegrasikan setiap fungsi atau persyaratan unik, TDD membantu pembuat kode mengembangkan model mental yang kuat dari kode yang sedang dikerjakan. Model mental ini membantu pengembang memvisualisasikan fungsi dan persyaratan kode secara keseluruhan saat mereka mengerjakannya. 

• Meningkatkan stabilitas sistem: Penggunaan pengembangan berbasis pengujian telah terbukti meningkatkan stabilitas aplikasi secara keseluruhan dengan menciptakan kode yang kuat dan teruji dengan baik, serta selaras dengan standar kepraktisan desain yang tinggi. 

Meskipun pengembangan berbasis pengujian (TDD) memiliki banyak manfaat, bukan berarti tidak ada tantangan. Meskipun tingkat keparahan tantangan ini bergantung pada proyek atau dapat dimitigasi dengan berbagai teknik lain, beberapa kelemahan TDD meliputi:

• Peningkatan volume kode: TDD mengharuskan pembuat kode menulis kode untuk setiap fitur yang diperlukan, sekaligus menguji setiap fitur. Menambahkan kode pengujian dengan kode produk akan menghasilkan basis kode keseluruhan yang lebih besar. 

• Kepercayaan diri palsu: Karena setiap fitur ditulis agar lulus pengujian, pembuat kode dan manajer proyek dapat merasakan kepercayaan diri palsu terhadap keseluruhan fungsionalitas kode. Meskipun setiap fitur terintegrasi diuji, TDD bukanlah pengganti kendali mutu dan pengujian API akhir, yang tetap diperlukan. 

• Peningkatan biaya overhead: TDD juga mengharuskan pembuat kode memelihara rangkaian pengujian yang besar di samping kode produksi mereka. Pemeliharaan basis kode pengujian memerlukan sejumlah sumber daya dan dapat menambah biaya overhead. 

• Penurunan efisiensi: Meskipun terbukti meningkatkan produktivitas, TDD dapat menunda pengembangan proyek karena menambahkan lebih banyak langkah dalam pembuatan dan implementasi setiap fitur baru. 

• Peningkatan waktu penyiapan: TDD mengharuskan pengembang untuk menyiapkan dan memelihara lingkungan pengujian yang sesuai untuk kode mereka. 

• Mengabaikan desain keseluruhan: Meskipun TDD membantu menyederhanakan kode dan meningkatkan desain, terlalu fokus pada setiap komponen dapat menyebabkan ketidakselarasan pada kode secara keseluruhan. Pembuat kode yang menggunakan TDD perlu mengetahui proses integrasi setiap pembaruan fitur ketika dikompilasi ke dalam aplikasi perangkat lunak secara keseluruhan.