Test-driven development: Perbedaan antara revisi

'''''Test-driven development''''' (TDD) adalah pendekatan untuk [[pengembangan perangkat lunak]] di mana praktisi melakukan ''interleave'' proses [[Pengujian perangkat lunak|pengujian]] dan pengembangan kode<ref>{{Cite book|title=Test Driven Development: By Example|url=https://archive.org/details/testdrivendevelo0000beck|last=Beck|first=Kent|publisher=Addison-Wesley|year=2002|isbn=|location=Boston|page=}}</ref> <ref name=":0">{{Cite journal|last=Jeffries|first=Ron|last2=Melnik|first2=Grigori|date=2007-05|title=Guest Editors' Introduction: TDD--The Art of Fearless Programming|url=http://dx.doi.org/10.1109/ms.2007.75|journal=IEEE Software|volume=24|issue=3|pages=24–30|doi=10.1109/ms.2007.75|issn=0740-7459}}</ref> 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 [[Agile Development Methods|metode ''agile'']] seperti [[Extreme programming|Extreme Programming]]. Namun, ini juga dapat digunakan dalam ''plan-driven development process''.<ref name=":1">{{Cite book|title=Software Engineering 9th Edition|last=Sommerville|first=Ian|publisher=Addison-Wesley|year=2011|isbn=|location=Boston|page=}}</ref>.

Proses TDD ditunjukkan oleh langkah-langkah berikut:<ref name=":1" />:

# Praktisi mulai dengan mengidentifikasi penambahan fungsi yang diperlukan. Fungsi ini biasanya kecil dan dapat diterapkan dalam beberapa baris kode.<ref name=":1" />.

# 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.<ref name=":1" />.

# Setelah semua pengujian berhasil, praktisi beralih ke mengimplementasikan fungsionalitas berikutnya.<ref name=":1" />.

Lingkungan pengujian otomatis, seperti JUnit yang mendukung ''Java Program Testing'' ,<ref>Massol, V. and Husted, T. (2003). ''JUnit in Action''. Greenwich, Conn.: Manning Publications Co. </ref>, 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.<ref name=":1" />.

Argumen yang kuat untuk ''Test-driven Development'' adalah bahwa hal itu membantu ''[[Pemrogram|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.<ref name=":1" />.

Selain pemahaman masalah yang lebih baik, manfaat lain dari ''Test-driven Development'' adalah:<ref name=":1" />:

'''Cakupan kode ''(code coverage)'''''<nowiki/>'':'' 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.<ref name=":1" />.

'''Pengujian regresi ''(regression testing)'''''<nowiki/>'':'' 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.<ref name=":1" />.

'''''Debugging'' sederhana ''(simplified debugging)'''''<nowiki/>'':'' 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.<ref name=":1" /><ref>{{Cite journal|last=Martin|first=Robert C.|date=2007-05|title=Professionalism and Test-Driven Development|url=http://dx.doi.org/10.1109/ms.2007.85|journal=IEEE Software|volume=24|issue=3|pages=32–36|doi=10.1109/ms.2007.85|issn=0740-7459}}</ref><ref name=":1" />.

'''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.<ref name=":1" />.

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 seringkalisering 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.<ref name=":1" />.

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.<ref name=":1" />.

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.<ref name=":1" />.

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.<ref>{{Cite journal|last=Andrea|first=Jennitta|date=2007-05|title=Envisioning Next-Generation Functional Testing Tools|url=http://dx.doi.org/10.1109/ms.2007.73|journal=IEEE Software|volume=24|issue=3|pages=58–66|doi=10.1109/ms.2007.73|issn=0740-7459}}</ref>.

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.<ref name=":0" />. 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.<ref name=":1" />.