Apa yang dimaksud dengan Test Driven Development (TDD)?

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

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

Pemrograman dengan metode ini memperkuat hubungan antara pengodean, pengujian (dalam bentuk unit test 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.

Melalui identifikasi dan penanganan kesalahan secara segera, pengembang yang menggunakan TDD dapat mencegah masalah kecil berkembang menjadi masalah yang lebih besar. Pengembangan berbasis pengujian memaksa pengembang memvalidasi dan menyempurnakan kode selama proses pengembangan, sehingga menyederhanakan pemeriksaan kualitas akhir dan perbaikan.

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

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

Pengembangan berbasis pengujian membalik proses pengembangan tradisional melalui penempatan pengujian sebelum pengembangan. Sebagai pendekatan iteratif, pengembangan berbasis pengujian meningkatkan kualitas dan keterbacaan kode melalui dorongan alur kerja yang dapat diuji serta menghasilkan kode berkualitas tinggi pada tingkat unit. Ketika menerapkan unit test, pengembang berfokus pada sebagian kecil logika, misalnya sebuah algoritme. Menulis kode secara khusus agar lulus pengujian tidak hanya menghasilkan kode yang lebih bersih dan andal, tetapi juga membantu meningkatkan dokumentasi.

Terdapat dua tingkat utama dalam pengembangan berbasis pengujian.

Pada acceptance test-driven development (ATDD), yang berkaitan erat dengan behavior-driven development (BDD), pemrogram menulis satu pengujian penerimaan lalu kode baru yang cukup untuk lulus pengujian tersebut. Pengujian penerimaan terkadang disebut customer test atau customer acceptance test.

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

Terkadang cukup disebut TDD, developer TDD mengharuskan pembuat kode menulis satu pengujian untuk mengevaluasi solusinya sendiri terhadap pengujian ATDD tersebut. Developer TDD 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 disempurnakan (dalam proses yang dikenal sebagai pemfaktoran ulang atau refactoring) agar hanya menyertakan elemen yang penting. Pengembang kemudian mengulangi proses ini bagi setiap fungsi perangkat lunak berikutnya. 

Proses pengembangan berbasis pengujian dibagi menjadi lima langkah terpisah:

1. Sebelum menulis kode bagi fungsi perangkat lunak tertentu, pengembang terlebih dahulu menulis satu unit test bagi 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 false positive. Jika kode lulus, hal 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 di-refactor untuk disederhanakan dan menghilangkan kode yang tidak perlu.

5. Ketika perangkat lunak yang telah di-refactor secara memadai berhasil lulus pengujian, pengembang beralih ke fungsi perangkat lunak yang diinginkan berikutnya. Penguji kemudian menulis dan menjalankan pengujian bagi setiap fitur baru.

Secara sederhana, proses pengembangan berbasis pengujian mengikuti siklus yang berulang, yang disebut siklus red-green-refactor. Tahapan siklusnya:

• Red: Menulis pengujian yang gagal bagi perilaku perangkat lunak yang diinginkan.

• Green: Menulis kode tambahan yang cukup untuk lulus pengujian.

• Refactor: Menyempurnakan kode untuk memenuhi standar kesederhanaan semaksimal 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 1990-an. Sebelum itu, kerangka kerja pengujian memisahkan pengembang dari pengujian basis kode mereka sendiri. Namun, seiring perkembangan rekayasa perangkat lunak, tim DevOps membutuhkan metodologi yang lebih cepat dan fleksibel untuk memenuhi permintaan stakeholder, terutama ketika berhadapan dengan kebutuhan stakeholder yang berubah cepat.

Pengembangan berbasis pengujian dikembangkan dari dan bersama berbagai kerangka kerja pengujian baru, serta telah diadopsi sebagai komponen modular pada 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 agile 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 masukan (input tape), mengetikkan secara manual pita keluaran (output tape) yang kita harapkan, lalu memprogram hingga pita keluaran sebenarnya sesuai dengan keluaran 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 penting dalam evolusi pengembangan berbasis pengujian meliputi:

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

• 1990: Pada awal dekade tersebut, 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. Black-box testing menggunakan penguji yang, secara kritis, tidak memiliki pengetahuan mengenai cara kerja internal perangkat lunak terkait.

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

• 1999–2002: Seiring maraknya gerakan pengembangan agile, Kent Beck mengembangkan konsep Extreme Programming, dengan mengodifikasi pengembangan berbasis pengujian dan memperkenalkan konsep penting mock object. TDD menggunakan mock object untuk menyimulasikan perilaku dependensi nyata (misalnya, database, layanan eksternal, dan sebagainya) selama pengujian. Metode ini membantu pengembang memfokuskan kode pengujian pada mock object yang dapat dipelihara dan dapat diverifikasi agar bekerja secara akurat. Pengujian yang gagal dengan menggunakan mock object dapat mengeliminasi 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 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 mengenai proyeknya dan membantu mendorong desain program. Melalui pemusatan 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 pengembangan berbasis pengujian meliputi:

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

• Meningkatkan dokumentasi: Dengan alasan yang sama, TDD juga menyediakan dokumentasi dan spesifikasi yang andal. Dokumentasi tersebut membantu pengembang, manajer proyek, dan stakeholder lainnya memvalidasi fitur dan persyaratan kode serta menjaga keteraturan sepanjang siklus proyek. 

• Meningkatkan kepercayaan diri: Pengembang dan tim DevOps yang menggunakan TDD memperoleh kepercayaan diri yang lebih besar, tidak hanya terhadap kode, tetapi juga terhadap pengujiannya.

• Memfasilitasi integrasi berkelanjutan: TDD sangat sesuai bagi praktik integrasi berkelanjutan, yang membuat kode aktif (live code) terus diperbarui dengan fitur dan patch baru.

• Mengurangi debugging: TDD menempatkan pengujian di awal proses pengembangan, sehingga mengurangi kebutuhan akan debugging yang ekstensif pada akhir pengembangan.

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

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

• Meningkatkan kualitas desain: Langkah ketiga yang penting dalam siklus TDD red-green-refactor mengharuskan pengembang melakukan refactoring dan menyederhanakan kode. Praktik ini meningkatkan kualitas desain secara umum.

• Memperkuat model mental: Melalui pemeriksaan dan pengintegrasian setiap fungsi atau persyaratan unik, TDD membantu pembuat kode mengembangkan model mental yang kuat atas kode yang sedang dikerjakan. Model mental ini membantu pengembang memvisualisasikan fungsi dan persyaratan kode secara keseluruhan saat mengerjakannya.

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

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

• Peningkatan volume kode: TDD mengharuskan pembuat kode menulis kode bagi setiap fitur yang diperlukan, sekaligus menguji setiap fitur. Penambahan kode pengujian pada kode produk 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 yang palsu terhadap keseluruhan fungsionalitas kode. Meskipun setiap fitur terintegrasi diuji, TDD bukanlah pengganti kendali mutu dan pengujian API akhir, yang tetap diperlukan.

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

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

• Peningkatan waktu penyiapan: TDD mengharuskan pengembang menyiapkan dan memelihara lingkungan pengujian yang sesuai bagi kodenya.

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