TDD : Sebuah Teknik Pengembangan Software, Bukan Teknik Testing
--
Istilah TDD atau Test-driven Development merupakan sesuatu yang tidak asing bagi kita para software engineer. Hampir seluruh sumber belajar yang ada mendorong kita untuk melakukan TDD pada proses pengembangan software. Namun, untuk apa kita mengikuti aturan itu? Apa manfaatnya bagi kita sebagai software engineer?
Memang benar, keuntungan dari penerapan TDD sulit untuk dilihat secara langsung. Sehingga, banyak yang berpikir bahwa ada atau tidaknya TDD tidak akan memiliki pengaruh yang signifikan. Padahal, ada banyak keuntungan yang dapat diperoleh dari penerapan TDD. Pada artikel ini, saya akan membahas bagaimana saya menerapkan TDD dalam proyek saya dan keuntungan yang saya peroleh.
Let’s start with the basics. Apa itu TDD?
Menurut buku Test-Driven Development by Example,
Test-driven development (TDD) is not, despite its name, a testing technique but rather a development technique in which the tests are written prior to the source code (Beck, 2003).
TDD merupakan suatu pendekatan dalam proses pengembangan software, dimana test dibuat terlebih dahulu sebelum source code yang divalidasi. Tiap baris source code harus di test dengan baik. TDD dilakukan secara incremental, dilakukan terus setiap ada penambahan fungsionalitas. Secara garis besar, TDD terdiri dari 3 tahap utama yaitu RED — GREEN — REFACTOR. Berikut merupakan ilustrasinya:
Terlihat bahwa TDD bukan suatu proses yang linear, melainkan sebuah siklus. Maka, pelaksanaan TDD dilakukan secara berkelanjutan, dimana TDD akan terus dilakukan selama ada penambahan fungsionalitas baru.
Untuk memahami lebih dalam, mari kita lihat bagaimana TDD diterapkan dalam proses pengembangan software.
- Pilih sebuah fungsionalitas yang akan diimplementasi.
- [RED] buat test untuk source code yang akan memenuhi fungsionalitas tersebut.
- [RED] jalankan test untuk memastikan bahwa test yang baru dibuat gagal. Ingat! Gagal (failed) dan error adalah dua hal yang berbeda.
- [GREEN] buat source code minimal untuk memenuhi fungsionalitas.
- [GREEN] jalankan test untuk memastikan bahwa source code lulus tes tanpa masalah.
- [REFACTOR] perbaiki source code tanpa mengubah fungsionalitas. Perbaikan dapat berupa perubahan struktur program atau penerapan aturan clean code.
- Ulangi langkah 1 untuk fungsionalitas selanjutnya.
Haruskah kita melakukan TDD? Mari pertimbangkan kelebihan dan kekuranganya.
Kelebihan TDD
Meminimalisir bug dan error tak terduga — Test membantu mencegah munculnya bug dan error tak terduga saat rilis. Hal ini akan terasa keuntungannya apabila source code yang dibuat memiliki jumlah baris yang banyak. Tentunya, akan sulit untuk memastikan secara manual bahwa source code tersebut bebas bug dan error.
Program berkualitas tinggi — Test secara tidak langsung mendokumentasi source code. Dengan test, kita dapat mengetahui bagaimana source code seharusnya berfungsi. Selain itu, TDD mewujudkan modularitas, karena dilakukan secara incremental untuk tiap fungsionalitas.
Mempermudah maintenance — Karena TDD mendokumentasikan kode dan mewujudkan modularitas, maka source code akan lebih mudah untuk di debug. Hal ini dapat menghemat waktu dan usaha dari software engineer.
(Bonus) It’s satisfying to look at — Sebagai software engineer, akan timbul perasaan puas apabila berhasil melihat RED — GREEN — REFACTOR yang terimplementasi dengan benar pada commit history. Apalagi jika pipeline-nya sesuai dengan commit message.
Kekurangan TDD
Membutuhkan usaha dan waktu ekstra untuk implementasinya — Membuat test memakan waktu, karena kita harus membayangkan apa saja fungsionalitas yang harus ada meski source code-nya belum ada.
Terkadang sulit untuk membuat test — Ada beberapa kasus dimana pembuatan test lebih sulit dari pembuatan source code-nya sendiri. Selain itu, sulit membuat test untuk source code yang implementasinya belum selesai sepenuhnya karena alasan tertentu.
Kesimpulan
Seperti yang dapat kita lihat, dibalik kekurangan TDD, terdapat lebih banyak keuntungan yang dapat diperoleh dari implementasinya. A small price to pay, I would say. Mungkin keuntungannya tidak langsung terlihat, tapi dalam jangka panjang, kalian akan merasakan keuntungan dari penerapan TDD!
Penerapan TDD dalam proses pengembangan software.
Tahapan TDD yang saya lakukan.
Saya menerapkan TDD pada proses penyelesaian proyek kuliah saya, yaitu membuat sebuah aplikasi mobile. Source code aplikasi ini lumayan kompleks dan cakupannya cukup luas, sehingga TDD dapat membantu meminimalisir bug dan error. Sebagai contoh, berikut adalah implementasi TDD untuk backend fitur laporan pengembalian uang:
[RED] membuat model untuk laporan pengembalian uang. Namun, model tersebut belum memiliki atribut apa-apa.
[RED] membuat test untuk model laporan pengembalian uang. Test ini menguji apakah atribut model sesuai, baik saat dibuat maupun diubah.
[GREEN] membuat implementasi model untuk memenuhi test.
[GREEN] jalankan test untuk memastikan bahwa source code lulus test.
[RED] membuat test untuk serializer laporan pengembalian uang.
[GREEN] membuat implementasi serializer untuk memenuhi test.
[GREEN] jalankan test untuk memastikan bahwa source code lulus test.
Loh, kok tidak ada tahap refactor?
Pada dasarnya, refactor bersifat opsional, hanya dilakukan apabila dirasa perlu. Saya tidak melakukan refactor, karena saya tidak menemukan code smell atau potongan kode yang menyalahi aturan clean code. Alhasil, saya langsung lanjut ke fungsionalitas berikutnya.
Even frontend needs TDD too!
Dari tadi kita membahas istilah fungsionalitas, sehingga banyak yang akan berpikir bahwa source code yang dimaksud merupakan source code backend. Jangan salah, ternyata TDD juga berlaku untuk frontend loh!
Meski hanya tampilan, ternyata tampilan tersebut tetap merupakan bagian dari fungsionalitas sehingga perlu diterapkan TDD. Sebagai contoh, berikut adalah implementasi TDD untuk frontend komponen progress bar:
[RED] membuat class yang akan mengimplementasi progress bar. Class ini belum ada implementasinya, hanya mengembalikan container kosong.
[RED] membuat test untuk progress bar. Test ini menguji apakah tampilan progress bar sudah sesuai dengan yang diharapkan.
[GREEN] membuat implementasi untuk memenuhi test.
[GREEN] jalankan test untuk memastikan bahwa source code lulus test.
[REFACTOR] refactor untuk memenuhi kaidah clean code.
Dapat kita simpulkan bahwa baik source code frontend maupun backend, keduanya dapat diimplementasikan dengan TDD. Sehingga, kita perlu memastikan bahwa TDD sudah terimplementasi dengan baik untuk tiap baris source code pada software yang dikembangkan. Bagaimana caranya? Salah satu caranya bisa dengan memperhatikan code coverage.
Apakah 100% coverage cukup?
Hore! Kini kita sudah memahami pentingnya TDD dan bagaimana penerapannya dalam proses pengembangan software. Namun, jangan cepat puas! Karena, seorang software engineer harus mengusahakan agar code coverage software mencapai 100%.
Code coverage merupakan persentase dari source code kita yang telah di test. Semakin tinggi persentase coverage, berarti semakin banyak bagian dari software yang telah di test. Namun, hal tersebut bukan berarti kita hanya mengusahakan code coverage dari segi angka. Penting juga untuk memastikan bahwa test yang dibuat dapat menutupi seluruh skenario ketika fungsionalitas dijalankan. Sehingga, test dapat menemukan segala bug atau error yang tersembunyi sebelum software dirilis.
Kesimpulan: apakah TDD wajib?
Jawabannya tergantung pada software engineer-nya sendiri. Apakah berani mengambil resiko bahwa software bisa memiliki error atau bug tak terduga saat dirilis? Semua kembali ke tujuan penerapan TDD di awal. Apabila penerapannya hanya untuk mengejar angka code coverage, maka ada atau tidaknya TDD tidak akan berpengaruh secara signifikan. Sehingga, TDD wajib apabila software engineer memiliki tujuan ingin meminimalisir resiko error atau bug tak terduga saat launch.
Setelah mempelajari TDD, saya cukup menyesal sempat lebih memilih DDT pada awal-awal saya mengerjakan proyek pengembangan software. Kini, setelah memahami manfaat dan bagaimana implementasinya yang benar, saya sadar bahwa TDD tidak sesulit itu untuk diterapkan. Saya harap artikel ini dapat menimbulkan memiliki kesadaran yang sama tentang TDD pada pembaca sekalian! Sekian dan terima kasih.
Daftar pustaka:
[1] Beck, K., Test-Driven Development By Example, Addison-Wesley, Boston, MA, USA, 2003.
[2] Diep, M., Erdogmus, H., Layman, L., Shull, F., & Turhan, B., How Effective is Test-Driven Development?, O’Reilly Media, 2010.
