Mengenal Test-Driven Development

Test-Driven Development yang menjadi kunci seorang Developer naik level ke level yang lebih tinggi

Hello fellas, kembali lagi bersama saya Kiddy. Setelah sekian purnama ngga nulis karena saya sibuk pergi ke bulan pada akhirnya saya nulis juga. Mood saya kembali lagi semenjak foto saya yang viral di Instagram. Udah tau foto saya yang mana? Jelas yang ini.

Foto Saya saat Aksi Nasional Tolak RKUHP, RUU KPK, RUU Permasyaratan, dan RUU lainnya

Nah pada kesempatan kali ini saya pengen berbagi insight kepada temen-temen tentang Test-Driven Development. Temen-temen tau ngga sih Test-Driven Development itu apa? Menurut wikipedia sih kaya gini:

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved so that the tests pass.

Yang intinya adalah TDD merupakan sebuah proses pada pembuatan perangkat lunak yang sangat bergantung kepada uji coba yang berulang dan berubah-ubah kasusnya sesuai kebutuhan dengan harapan program yang dibangun dapat memenuhi uji coba.

Mungkin selama ini temen-temen saat uji coba perangkat lunak paling sekedar klik-klik doang, ya ngga? Ngaku deh pasti abis bikin CRUD langsung nyoba aja CRUDnya dengan cara visit masing-masing routenya terus nyoba-nyoba manual, ya kan?

Sebenernya cara itu ngga salah temen-temen, yang ngga salah ya kalo asal deploy tapi belom dicoba hihihihi, bisa-bisa tuh program ambyar waktu di production.

Nah TDD ini sebenernya salah satu requirement untuk menjadi seorang developer kelas senior atau expert. Kenapa gitu? Karena dengan TDD, kita bisa melakukan ekspektasi atau uji coba terhadap tiap baris kode yang kita tulis kita tanpa perlu banyak effort atau membuang tenaga dengan cara melakukan visit secara manual. Bahkan menurut saya, teknik TDD jauh lebih efisien daripada nyoba satu-satu ketika aplikasi yang dibangun sudah besar.

Selain itu TDD juga merupakan pertanyaan yang paling sering keluar ketika kamu ngelamar ke sebuah perusahaan teknologi sekelas Gojek, Tokopedia, Bukalapak, atau bahkan Shopee pepepepepepepe di shopeepepepepepepe, terngiang-ngiang ronaldo joget 😆.

Meskipun TDD adalah salah satu kerjaan QA Engineer, tapi bukan berarti kita sebagai developer tidak harus belajar TDD, justru kita juga harus paham karena kalau kantormu tidak punya QA Engineer ya tentu saja kamu yang diminta untuk melakukan QA-nya 😆.

Oke sekarang kita lanjut. Dalam membuat TDD ada dua hal yang harus diperhatikan:

1. Ekspektasi
2. Aktual

Ekspektasi adalah hasil yang kita harapkan, sebagai contoh misalnya saya suka sama dia. Sedangkan aktual adalah hal yang terjadi, sebagai contoh ya dia ngga suka sama saya.

Sedih sih pokoknya.

Nah setelah tau apa itu TDD dan dasarnya sekarang kita bahas manfaat TDD, ada beberapa manfaat versi saya:

1. Melakukan uji coba secara bersamaan tanpa perlu untuk mendapatkan hasil aktual dengan berbagai ekspektasi.
2. Mempermudah tracking code yang error dari sebuah ekspektasi, karena akan ada ekspektasi kita yang sangat random yang bahkan kita tidak sadar hal itu dapat menyebabkan error.
3. Mencegah redundant code dengan refactoring code (saya belum bahas ini, saya akan bahas di artikel selanjutnya).
4. Meningkatkan kapabilitas diri. Ingat sebagai Developer kita tidak boleh berhenti belajar, harus terus meningkatkan kapabilitas diri! Jangan jadi developer kalo mengeluh lelah belajar hal yang baru setiap hari.

Oke jadi gimana sih cara TDD bekerja?

src: https://dev.to/lypchenko/test-driven-development-method-and-how-to-use-it-4l2f

Kalo versi https://dev.to/lypchenko/test-driven-development-method-and-how-to-use-it-4l2f dibagi jadi lima, yaitu:

1. QA engineer creates a test to cover all the changes.
2. Developers write code according to specific system behavior.
3. Tests are launched to see if any fails.
4. The written code is refactored with a constant verification of test efficiency.
5. Steps above are repeated.

Gambaran teori diatas akan saya jelaskan seperti kasus dibawah ini:

1. Buat sebuah unit test untuk menguji coba URL yang kamu tuju, contoh kita ekspektasikan terdapat url method POST dengan path /login, lalu kita assert status code adalah 200, alias kita ekspektasikan URL tersebut ada dan mengembalikan status 200.
2. Jalankan unit test. Error? Tentu saja karena belum ada Controller dan path tersebut.
3. Buat sebuah Controller untuk path /login dengan method POST dan sambungkan ke routes.
4. Lakukan unit test kembali, test berhasil.
5. Lanjut untuk membuat test kedua, path /login dengan method POST akan menerima dua parameter JSON, yaitu email dan password, apabila terdapat email dan password, kembalikan response 200 lalu assert (pastikan) kembaliannya berupa json dimana terdapat key ‘values’.
6. Jalankan unit test, akan terdapat error, tentu saja karena tidak ada kembalian key values.
7. Kembali ke controller, kembalikan response berupa JSON dimana didalamnya terdapat key values dan tidak perlu diisi apapun, yang penting ada key values.
8. Jalankan unit test, sekarang unit test sudah berhasil pass.
9. Lanjut untuk membuat test ketiga, apabila path /login tidak memiliki email dan password, maka response wajib 400.
10. Jalankan unit test, error, tentu saja.
11. Kembali ke controller, sekarang buat kondisi apabila request tidak mengirimkan email dan password di body json, naikan exception dan kembalikan response 400.
12. Jalankan unit test, sekarang unit test sudah berhasil pass.
13. Ulangi untuk membuat langkah-langkah percobaan selanjutnya dengan berbagai kasus.
14. Setelah semua unit test yang dibuat dianggap cukup, barulah developer memeprbaiki semua code agar bisa sesuai ekspektasi dari semua unit test. Apabila developer selesai merapihkan code sesuai unit test, test harus kembali dijalankan dan semua unit test wajib untuk PASS tanpa FAILED satupun.

Kesimpulan, TDD merupakan salah satu teknik uji coba dalam dunia developer yang mempersingkat proses uji coba dengan berbagai ekspektasi.

TDD adalah perjalananmu dalam membuat program, semua harus dicoba dengan kasus per kasus, tentu saja diawal ekspektasi akan error karena memang belum terbuat, namun setelah error kita perbaiki controller dan kembali kita jalankan, sehingga diibaratkan seperti machine learning yang belajar dari kesalahan dan terus memperbaiki hal yang baru saja salah.

Laravel Logo Terbaru

Artikel yang membahas PHPUnit (TDD) ada disini, klik ya!

Bermain dengan PHP Unit Test di Laravel — Part 1