Test-driven development
Kelebihan dan Kekurangan TDD

Selain pemahaman masalah yang lebih baik, manfaat lain dari Test-driven Development adalah:
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.
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.
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.
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.
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.
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.
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.
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.
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.
↑  Beck, Kent (2002). Test Driven Development: By Example. Boston: Addison-Wesley.
1 2  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)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18  Sommerville, Ian (2011). Software Engineering 9th Edition. Boston: Addison-Wesley.
↑  Massol, V. and Husted, T. (2003). JUnit in Action. Greenwich, Conn.: Manning Publications Co.
↑  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)
↑  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)