Test-driven development

Test-driven development (TDD) adalah pendekatan untuk pengembangan perangkat lunak di mana praktisi melakukan interleave proses pengujian dan pengembangan kode^[1][2] Pada dasarnya, praktisi membangun kode secara bertahap, bersama dengan pengujian untuk increment itu. Praktisi tidak beralih ke increment berikutnya sampai kode yang dikembangkan lolos uji. Test-driven Development diperkenalkan sebagai bagian dari metode agile seperti Extreme Programming. Namun, ini juga dapat digunakan dalam plan-driven development process.^[3]

Proses TDD ditunjukkan oleh langkah-langkah berikut:^[3]

1. Praktisi mulai dengan mengidentifikasi penambahan fungsi yang diperlukan. Fungsi ini biasanya kecil dan dapat diterapkan dalam beberapa baris kode.^[3]
2. Praktisi menulis pengujian untuk fungsi ini dan mengimplementasikannya sebagai pengujian otomatis (automated testing). Ini berarti bahwa pengujian dapat dieksekusi dan akan melaporkan apakah telah lulus (pass) atau gagal (failed)^[3].
3. Praktisi kemudian menjalankan pengujian, bersama dengan semua pengujian lain yang telah dilaksanakan. Awalnya, praktisi belum mengimplementasikan fungsionalitasnya sehingga pengujian baru akan gagal. Hal ini disengaja karena menunjukkan bahwa pengujian menambahkan sesuatu ke test set^[3].
4. Praktisi kemudian mengimplementasikan fungsionalitas dan menjalankan kembali pengujian. Ini mungkin melibatkan refactoring kode yang ada untuk memperbaikinya dan menambahkan kode baru ke apa yang sudah ada.^[3]
5. Setelah semua pengujian berhasil, praktisi beralih ke mengimplementasikan fungsionalitas berikutnya.^[3]

Lingkungan pengujian otomatis, seperti JUnit yang mendukung Java Program Testing,^[4] sangat penting untuk TDD. Karena kode dikembangkan dalam increment yang sangat kecil, praktisi harus dapat menjalankan setiap pengujian setiap kali praktisi menambahkan fungsionalitas atau memperbaiki program. Oleh karena itu, pengujian ditanam dalam program terpisah yang menjalankan pengujian dan memanggil sistem yang sedang diuji. Dengan menggunakan pendekatan ini, dimungkinkan untuk menjalankan ratusan pengujian terpisah dalam beberapa detik.^[3]

Argumen yang kuat untuk Test-driven Development adalah bahwa hal itu membantu programmer menjelaskan ide-ide mereka tentang apa yang seharusnya dilakukan oleh setiap segmen kode. Untuk menulis pengujian, praktisi perlu memahami apa yang dimaksudkan, karena pemahaman ini memudahkan untuk menulis kode yang diperlukan. Tentu saja, jika praktisi memiliki pengetahuan atau pemahaman yang tidak lengkap, maka Test-driven Development tidak akan membantu. Jika praktisi tidak cukup tahu untuk menulis pengujian, praktisi tidak akan mengembangkan kode yang diperlukan. Misalnya, jika perhitungan praktisi melibatkan pembagian, praktisi harus memeriksa bahwa praktisi tidak membagi angka dengan nol. Jika praktisi lupa menulis pengujian untuk ini, maka kode yang akan diperiksa tidak akan pernah dimasukkan dalam program.^[3]

Selain pemahaman masalah yang lebih baik, manfaat lain dari Test-driven Development adalah:^[3]

Cakupan kode (code coverage): Pada prinsipnya, setiap segmen kode yang praktisi tulis harus memiliki setidaknya satu pengujian terkait. Oleh karena itu, praktisi dapat yakin bahwa semua kode dalam sistem sebenarnya telah dieksekusi. Kode diuji saat ditulis sehingga cacat ditemukan pada awal proses pengembangan.^[3]

Pengujian regresi (regression testing): Sebuah test suite dikembangkan secara bertahap ketika suatu program dikembangkan. Praktisi selalu dapat menjalankan pengujian regresi untuk memeriksa bahwa perubahan pada program belum memperkenalkan bug baru.^[3]

Debugging sederhana (simplified debugging): Ketika pengujian gagal, itu harus jelas di mana masalahnya. Kode yang baru ditulis perlu diperiksa dan dimodifikasi. Praktisi tidak perlu menggunakan alat debugging untuk menemukan masalahnya. Laporan tentang penggunaan TDD menunjukkan bahwa hampir tidak pernah diperlukan untuk menggunakan debugger otomatis dalam TDD.^[3][5]

Dokumentasi sistem (system documentation): Pengujian itu sendiri bertindak sebagai bentuk dokumentasi yang menggambarkan apa yang harus dilakukan kode. Membaca pengujian dapat membuatnya lebih mudah untuk memahami kode.^[3]

Salah satu manfaat paling penting dari TDD adalah berkurangnya biaya pengujian regresi. Pengujian regresi melibatkan menjalankan set pengujian yang telah berhasil dijalankan setelah perubahan dilakukan pada suatu sistem. Pengujian regresi memeriksa bahwa perubahan-perubahan ini belum memperkenalkan bug baru ke dalam sistem dan bahwa kode baru berinteraksi seperti yang diharapkan dengan kode yang ada. Pengujian regresi sangat mahal dan sering kali tidak praktis ketika suatu sistem diuji secara manual, karena biaya dalam waktu dan upaya sangat tinggi. Dalam situasi seperti itu, praktisi harus mencoba dan memilih pengujian yang paling relevan untuk dijalankan kembali dan mudah untuk melewatkan pengujian yang penting.^[3]

Namun, pengujian otomatis, yang merupakan hal mendasar untuk menguji pengembangan pertama, secara dramatis mengurangi biaya pengujian regresi. Pengujian yang ada dapat dijalankan kembali dengan cepat dan murah. Setelah membuat perubahan pada sistem dalam pengembangan uji-pertama, semua pengujian yang ada harus berjalan dengan sukses sebelum fungsionalitas lebih lanjut ditambahkan. Sebagai seorang programmer, praktisi dapat yakin bahwa fungsionalitas baru yang telah praktisi tambahkan belum menyebabkan atau mengungkapkan masalah dengan kode yang ada.^[3]

TDD paling banyak digunakan dalam pengembangan perangkat lunak baru di mana fungsi tersebut diimplementasikan dalam kode baru atau dengan menggunakan library standar yang telah teruji dengan baik. Jika praktisi menggunakan kembali komponen kode besar atau sistem lawas (legacy system) maka praktisi perlu menulis pengujian untuk sistem ini secara keseluruhan. TDD mungkin juga tidak efektif dengan sistem multi-threaded. Thread yang berbeda dapat disisipkan pada waktu yang berbeda dalam uji coba yang berbeda, sehingga dapat menghasilkan hasil yang berbeda.^[3]

Jika praktisi menggunakan TDD, praktisi masih memerlukan proses pengujian sistem untuk memvalidasi sistem; yaitu, untuk memeriksa apakah memenuhi kebutuhan semua pemangku kepentingan sistem. Pengujian sistem juga menguji kinerja (performance), reliability, dan memeriksa bahwa sistem tidak melakukan hal-hal yang seharusnya tidak dilakukan, seperti menghasilkan keluaran yang tidak diinginkan, dll. Andrea (2007) menyarankan bagaimana alat pengujian dapat diperluas untuk mengintegrasikan beberapa aspek pengujian sistem dengan TDD.^[6]

TDD telah terbukti sebagai pendekatan yang berhasil untuk proyek-proyek kecil dan menengah. Secara umum, programmer yang telah mengadopsi pendekatan ini senang dengan itu dan menemukan cara yang lebih produktif untuk mengembangkan perangkat lunak.^[2] Dalam beberapa uji coba, telah terbukti menyebabkan peningkatan kualitas kode; di negara lain, hasilnya tidak meyakinkan. Namun, tidak ada bukti bahwa TDD mengarah pada kode kualitas yang lebih buruk.^[3]

1. ^ Beck, Kent (2002). Test Driven Development: By Example. Boston: Addison-Wesley. 
2. ^ ^{a b} Jeffries, Ron; Melnik, Grigori (2007-05). "Guest Editors' Introduction: TDD--The Art of Fearless Programming". IEEE Software. 24 (3): 24–30. doi:10.1109/ms.2007.75. ISSN 0740-7459.  Periksa nilai tanggal di: |date= (bantuan)
3. ^ ^{a b c d e f g h i j k l m n o p q r} Sommerville, Ian (2011). Software Engineering 9th Edition. Boston: Addison-Wesley. 
4. ^ Massol, V. and Husted, T. (2003). JUnit in Action. Greenwich, Conn.: Manning Publications Co.
5. ^ Martin, Robert C. (2007-05). "Professionalism and Test-Driven Development". IEEE Software. 24 (3): 32–36. doi:10.1109/ms.2007.85. ISSN 0740-7459.  Periksa nilai tanggal di: |date= (bantuan)
6. ^ Andrea, Jennitta (2007-05). "Envisioning Next-Generation Functional Testing Tools". IEEE Software. 24 (3): 58–66. doi:10.1109/ms.2007.73. ISSN 0740-7459.  Periksa nilai tanggal di: |date= (bantuan)