Test-driven development: Perbedaan antara revisi
Konten dihapus Konten ditambahkan
k Mimihitam memindahkan halaman Test-driven Development ke Test-driven development |
k Bot: Perubahan kosmetika |
||
Baris 1:
'''''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|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 ==
Baris 29:
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
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" />.
| |||