Lompat ke isi

Test-driven development: Perbedaan antara revisi

Ensiklopedia Pengetahuan Universitas Islam Sultan Agung

Maintenance script (bicara | kontrib)

37.956 suntingan
Maintenance script (bicara | kontrib)
37.956 suntingan
Impor teks terkontrol dari Wikipedia bahasa Indonesia; revisi 27852106; atribusi sumber disertakan.
 
Maintenance script (bicara | kontrib)
37.956 suntingan
Presentation V4: sitasi, referensi, Math, Wikimedia Commons, dan atribusi
 
Baris 1: 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 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''.
'''''Test-driven development''''' (TDD) adalah pendekatan untuk [[pengembangan perangkat lunak]] di mana praktisi melakukan ''interleave'' proses [[Pengujian perangkat lunak|pengujian]] dan pengembangan kode<ref>Kent Beck. [https://archive.org/details/testdrivendevelo0000beck Test Driven Development: By Example]. Addison-Wesley. 2002.</ref><ref>Ron Jeffries. [http://dx.doi.org/10.1109/ms.2007.75 Guest Editors' Introduction: TDD--The Art of Fearless Programming]. ''IEEE Software''. 2007-05. Vol. 24 (3). hlm. 24–30. doi:10.1109/ms.2007.75.</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>Ian Sommerville. ''Software Engineering 9th Edition''. Addison-Wesley. 2011.</ref>


== Proses TDD ==
== Proses TDD ==
Proses TDD ditunjukkan oleh langkah-langkah berikut:
Proses TDD ditunjukkan oleh langkah-langkah berikut:<ref>Ian Sommerville. ''Software Engineering 9th Edition''. Addison-Wesley. 2011.</ref>


# Praktisi mulai dengan mengidentifikasi penambahan fungsi yang diperlukan. Fungsi ini biasanya kecil dan dapat diterapkan dalam beberapa baris kode.
# Praktisi mulai dengan mengidentifikasi penambahan fungsi yang diperlukan. Fungsi ini biasanya kecil dan dapat diterapkan dalam beberapa baris kode.<ref>Ian Sommerville. ''Software Engineering 9th Edition''. Addison-Wesley. 2011.</ref>
# 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)''''.''
# 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)''<ref>Ian Sommerville. ''Software Engineering 9th Edition''. Addison-Wesley. 2011.</ref>''.''
# 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''''.''
# 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''<ref>Ian Sommerville. ''Software Engineering 9th Edition''. Addison-Wesley. 2011.</ref>''.''
# 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.
# 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>Ian Sommerville. ''Software Engineering 9th Edition''. Addison-Wesley. 2011.</ref>
# Setelah semua pengujian berhasil, praktisi beralih ke mengimplementasikan fungsionalitas berikutnya.
# Setelah semua pengujian berhasil, praktisi beralih ke mengimplementasikan fungsionalitas berikutnya.<ref>Ian Sommerville. ''Software Engineering 9th Edition''. Addison-Wesley. 2011.</ref>


Lingkungan pengujian otomatis, seperti JUnit yang mendukung ''Java Program Testing'', 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.
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>Ian Sommerville. ''Software Engineering 9th Edition''. Addison-Wesley. 2011.</ref>


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.
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>Ian Sommerville. ''Software Engineering 9th Edition''. Addison-Wesley. 2011.</ref>


== Kelebihan dan Kekurangan TDD ==
== Kelebihan dan Kekurangan TDD ==
Selain pemahaman masalah yang lebih baik, manfaat lain dari ''Test-driven Development'' adalah:
Selain pemahaman masalah yang lebih baik, manfaat lain dari ''Test-driven Development'' adalah:<ref>Ian Sommerville. ''Software Engineering 9th Edition''. Addison-Wesley. 2011.</ref>


'''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.
'''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>Ian Sommerville. ''Software Engineering 9th Edition''. Addison-Wesley. 2011.</ref>


'''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.
'''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>Ian Sommerville. ''Software Engineering 9th Edition''. Addison-Wesley. 2011.</ref>


'''''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.
'''''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>Ian Sommerville. ''Software Engineering 9th Edition''. Addison-Wesley. 2011.</ref><ref>Robert C. Martin. [http://dx.doi.org/10.1109/ms.2007.85 Professionalism and Test-Driven Development]. ''IEEE Software''. 2007-05. Vol. 24 (3). hlm. 32–36. doi:10.1109/ms.2007.85.</ref>


'''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.
'''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>Ian Sommerville. ''Software Engineering 9th Edition''. Addison-Wesley. 2011.</ref>


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.
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.<ref>Ian Sommerville. ''Software Engineering 9th Edition''. Addison-Wesley. 2011.</ref>


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.
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>Ian Sommerville. ''Software Engineering 9th Edition''. Addison-Wesley. 2011.</ref>


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.
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>Ian Sommerville. ''Software Engineering 9th Edition''. Addison-Wesley. 2011.</ref>


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.
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>Jennitta Andrea. [http://dx.doi.org/10.1109/ms.2007.73 Envisioning Next-Generation Functional Testing Tools]. ''IEEE Software''. 2007-05. Vol. 24 (3). hlm. 58–66. doi:10.1109/ms.2007.73.</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. 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.
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>Ron Jeffries. [http://dx.doi.org/10.1109/ms.2007.75 Guest Editors' Introduction: TDD--The Art of Fearless Programming]. ''IEEE Software''. 2007-05. Vol. 24 (3). hlm. 24–30. doi:10.1109/ms.2007.75.</ref> 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>Ian Sommerville. ''Software Engineering 9th Edition''. Addison-Wesley. 2011.</ref>


== Referensi ==
== Referensi ==
 
<references />
 


== Sumber dan atribusi ==
== Sumber dan atribusi ==


Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Test-driven+development&oldid=27852106 Wikipedia bahasa Indonesia], revisi 27852106 (2025-09-18T11:58:59Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku.
Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Test-driven+development&oldid=27852106 Wikipedia bahasa Indonesia], revisi 27852106 (2025-09-18T11:58:59Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku.
<!-- WIKI_UNISSULA_PRESENTATION_V4 -->

Revisi terkini sejak 23 Agustus 2026 10.23

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

Proses TDD ditunjukkan oleh langkah-langkah berikut:[4]

  1. Praktisi mulai dengan mengidentifikasi penambahan fungsi yang diperlukan. Fungsi ini biasanya kecil dan dapat diterapkan dalam beberapa baris kode.[5]
  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)[6].
  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[7].
  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.[8]
  5. Setelah semua pengujian berhasil, praktisi beralih ke mengimplementasikan fungsionalitas berikutnya.[9]

Lingkungan pengujian otomatis, seperti JUnit yang mendukung Java Program Testing,[10] 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.[11]

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.[12]

Kelebihan dan Kekurangan TDD

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

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.[14]

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.[15]

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.[16][17]

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.[18]

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.[19]

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.[20]

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.[21]

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.[22]

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.[23] 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.[24]

Referensi

  1. ↑ Kent Beck. Test Driven Development: By Example. Addison-Wesley. 2002.
  2. ↑ Ron Jeffries. Guest Editors' Introduction: TDD--The Art of Fearless Programming. IEEE Software. 2007-05. Vol. 24 (3). hlm. 24–30. doi:10.1109/ms.2007.75.
  3. ↑ Ian Sommerville. Software Engineering 9th Edition. Addison-Wesley. 2011.
  4. ↑ Ian Sommerville. Software Engineering 9th Edition. Addison-Wesley. 2011.
  5. ↑ Ian Sommerville. Software Engineering 9th Edition. Addison-Wesley. 2011.
  6. ↑ Ian Sommerville. Software Engineering 9th Edition. Addison-Wesley. 2011.
  7. ↑ Ian Sommerville. Software Engineering 9th Edition. Addison-Wesley. 2011.
  8. ↑ Ian Sommerville. Software Engineering 9th Edition. Addison-Wesley. 2011.
  9. ↑ Ian Sommerville. Software Engineering 9th Edition. Addison-Wesley. 2011.
  10. ↑ Massol, V. and Husted, T. (2003). JUnit in Action. Greenwich, Conn.: Manning Publications Co.
  11. ↑ Ian Sommerville. Software Engineering 9th Edition. Addison-Wesley. 2011.
  12. ↑ Ian Sommerville. Software Engineering 9th Edition. Addison-Wesley. 2011.
  13. ↑ Ian Sommerville. Software Engineering 9th Edition. Addison-Wesley. 2011.
  14. ↑ Ian Sommerville. Software Engineering 9th Edition. Addison-Wesley. 2011.
  15. ↑ Ian Sommerville. Software Engineering 9th Edition. Addison-Wesley. 2011.
  16. ↑ Ian Sommerville. Software Engineering 9th Edition. Addison-Wesley. 2011.
  17. ↑ Robert C. Martin. Professionalism and Test-Driven Development. IEEE Software. 2007-05. Vol. 24 (3). hlm. 32–36. doi:10.1109/ms.2007.85.
  18. ↑ Ian Sommerville. Software Engineering 9th Edition. Addison-Wesley. 2011.
  19. ↑ Ian Sommerville. Software Engineering 9th Edition. Addison-Wesley. 2011.
  20. ↑ Ian Sommerville. Software Engineering 9th Edition. Addison-Wesley. 2011.
  21. ↑ Ian Sommerville. Software Engineering 9th Edition. Addison-Wesley. 2011.
  22. ↑ Jennitta Andrea. Envisioning Next-Generation Functional Testing Tools. IEEE Software. 2007-05. Vol. 24 (3). hlm. 58–66. doi:10.1109/ms.2007.73.
  23. ↑ Ron Jeffries. Guest Editors' Introduction: TDD--The Art of Fearless Programming. IEEE Software. 2007-05. Vol. 24 (3). hlm. 24–30. doi:10.1109/ms.2007.75.
  24. ↑ Ian Sommerville. Software Engineering 9th Edition. Addison-Wesley. 2011.

Sumber dan atribusi

Konten artikel ini diadaptasi dari Wikipedia bahasa Indonesia, revisi 27852106 (2025-09-18T11:58:59Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku.


Diperoleh dari "https://wiki.unissula.ac.id/index.php?title=Test-driven_development&oldid=1748"