Kenyataan Penerapan TDD
Pada artikel yang saya buat sebelumnya, telah dijelaskan pentingnya prinsip agile untuk membuat proses pengembangan perangkat lunak menjadi lebih efektif. Salah satu prinsip agile sendiri adalah untuk memanfaatkan perubahan demi keuntungan kompetitif klien. Hanya saja, apakah penerapan urutan commit Red-Green-Refactor atau yang kita kenal sebagai TDD (Test Driven Development) itu akan membuat kita semakin agile atau malah sebaliknya?
Apa itu TDD?
Test-driven development (TDD) is a software development process relying on software requirements being converted to test cases before software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. This is opposed to software being developed first and test cases created later. — Wikipedia
Secara pragmatis, untuk bisa menerapkan TDD berikut ini:
- Tambahkan sebuah test. Sebelum membuat fitur yang baru, buatlah test yang memenuhi spesifikasi dari fitur tersebut. Hal ini diharapkan agar developer fokus terhadap requirement lebih dulu sebelum menulis kode.
- Jalankan semua test yang ada. Test yang baru dibuat diekspektasi gagal. Hal ini ditujukan agar kode baru diperlukan untuk fitur baru tadi.
- Buat kode sederhana yang bisa lolos test tersebut. Kode yang tidak elegan diperbolehkan selama bisa lolos test. Kode tersebut bisa diperbaiki pada tahap refactor yang mana tidak mengubah fungsionalitas program.
- Semua test diharapkan sudah pass. Jika ada test yang gagal, kode baru tadi harus diubah hingga lolos test. Hal ini diharapkan agar program bisa memenuhi requirement yang ada dan tidak merusak fitur yang sudah ada.
- Refactor seperlunya saja. Gunakan test sebelumnya guna menjamin fungsionalitas aplikasi terjaga. Pada tahap ini juga, kode diharapkan diubah agar bisa mencapai clean code. Pastikan juga agar tetap lolos semua test yang ada.
Dalam PPL agar praktik ini benar-benar bisa terasa secara eksplisit, digunakan awalan [RED] untuk membuat test, [GREEN] untuk membuat kode baru hingga pass test tadi, dan [REFACTOR] untuk refactoring kode yang ada.
Dari commit pada gitlab diatas terlihat terdapat 3 commit untuk RED,GREEN, dan REFACTOR.
Untuk tahap RED, bisa dilakukan dengan membuat kode test seperti dibawah ini. Dalam contoh ini, test menggunakan enzyme untuk React.js.
Selanjutnya kode implementasi dilakukan pada tahap GREEN dan lakukan refactor seperlunya saja.
Alasan TDD (bisa saja) tidak Efektif
[Disclaimer]: Berikut merupakan pendapat pribadi selama melakukan praktik TDD.
Dalam penerapan TDD, terutama bagi Developer yang masih awam seringkali ada masalah-masalah yang terjadi ketika menerapkan TDD sebagai berikut:
- Sulitnya menentukan kasus test yang tepat. Semakin kompleks kode yang dibuat, maka tentu test yang dibuat meningkat pula. Apabila potongan kode atau fungsi yang akan dibuat memiliki flow yang cukup kompleks, seringkali cukup sulit untuk membuat test yang tepat. Sehingga tak jarang, Developer menghabiskan lebih banyak waktu untuk membuat test dibandingkan fokus membuat aplikasi.
- Kualitas kode testing yang kurang baik. Karena poin awal tadi, seringkali Developer fokus hanya untuk membuat test yang memudahkannya. Test yang dibuat hanya semata-mata untuk meningkatkan Code Coverage saja. Hal tersebut tentu bisa merusak esensi dari TDD sendiri.
Alhasil agar bisa mengikuti perubahan requirement secara cepat, tak jarang kita harus mengorbankan sesuatu untuk mencapainya. Salah satu bagian program yang tidak akan dilihat dan berpengaruh secara langsung kepada klien yaitu testing. Beberapa implementasi testing bisa jadi diabaikan begitu saja atau kalaupun ada kualitas test yang dibuat tidak terlalu “bagus”.
Meskipun begitu, mengapa masih banyak yang memakai TDD dalam proses pengembangan perangkat lunak? Salah satu alasannya adalah dengan test yang dibuat sebelumnya, Developer bisa menjaga kualitas kode dengan baik. Program yang dibuat akan cenderung modular dan meminimalisir side-effect. Tentunya, hal ini hanya berlaku jika diterapkan dengan tepat.
Selain itu, penerapan TDD cenderung lebih cocok untuk software yang sudah besar dan dibuat oleh banyak orang. Hal ini karena apabila semakin banyak Developer yang bekerja, biasanya Developer cenderung memiliki asumsi sendiri terhadap fitur yang sudah ada. Keadaan tersebut semakin sering apabila dokumentasi jarang tersedia dan Developer lama sudah tidak aktif membuat Software. Sehingga, test tadi dapat menjadi jalan terakhir untuk tetap menjamin requirement yang ada.
Jadi, TDD bisa saja efektif dan malah mempercepat proses pengembangan perangkat lunak dalam jangka panjang. Hanya saja untuk kebanyakan Developer, membiasakan untuk TDD bukanlah hal yang mudah dan perlu proses yang cukup lama.
Referensi:
Beck, Kent (2002–11–08). Test-Driven Development by Example. Vaseem: Addison Wesley
Proffitt, Jacob. “TDD Proven Effective! Or is it?”. Retrieved 2008–02–21.
Adrian
