TDD the Series : Part 1 - Apa itu Test Driven Development (TDD)

Apa itu Test Driven Development dan keuntungan yang kita peroleh jika menerapkannya dalam pengembangan software

Wahyudi Wibowo
Koding Kala Weekend
6 min readApr 22, 2017

--

Image courtesy of http://www.agilenutshell.com/test_driven_development

Tulisan ini adalah bagian dari seri berjudul ‘TDD the Series’ yang terbagi menjadi 3 part :

  • Part 1 - Apa itu Test Driven Development (TDD)
  • Part 2 - Komponen-komponen di dalam Test
  • Part 3 - Mengenal Mocking dan Penggunaannya di dalam Test

Apakah teman-teman sudah pernah mendengar soal Test Driven Development atau TDD ? Ya, saya yakin banyak diantara kita yang sudah pernah mendengar istilah tersebut. TDD saat ini menjadi istilah yang hype di lingkungan teknologi informasi dan banyak orang atau perusahaan yang menjadikan TDD sebagai bagian penting dalam development cycle mereka. Sebenarnya apa itu TDD dan mengapa banyak orang yang bilang bahwa TDD membuat proses development menjadi lebih menyenangkan ? Mari kita bahas bersama.

Sekilas tentang Testing dan Mengapa Kita Memerlukan Automated Test

Sebelum kita masuk ke definisi TDD, mari kita bahas tentang pengembangan software secara konvensional yang biasa dilakukan oleh orang kebanyakan. Awalnya kita akan diberi software requirements atau daftar yang berisi spesifikasi software yang akan kita buat. Lalu kita mulai mengerjakan alias menulis kode sesuai permintaan. Setelah itu kita tes aplikasi kita apakah berjalan dengan baik dan apabila semuanya berjalan dengan baik dan benar, kita berikan aplikasi kita ke client untuk di tes lebih lanjut atau digunakan untuk produksi.

Sekilas tidak ada masalah bukan ?

Ya, skenario diatas akan berjalan lancar jika requirements tidak pernah berubah, yang sayangnya, hal itu jarang sekali atau tidak pernah terjadi 😅Dalam proses pengembangan software yang sesungguhnya, requirements akan selalu berubah mengikuti kebutuhan. Sehingga muncul masalah-masalah seperti :

  • Penambahan fitur membuat break kode yang sudah ada atau menambah bugs baru.
  • Kode yang break dan bugs seringkali tidak terdeteksi diawal sehingga terbawa sampai ke level production.
  • Developer menjadi tidak percaya diri dalam menambah, merubah, atau mengembangkan fitur karena takut aplikasi akan break.
  • Proses menemukan bugs secara manual yang memakan waktu lama dan sangat menjemukan.
It’s easy to kill bugs they say…

Oleh karena itu, kita memerlukan automated test untuk mengecek apakah baris kode yang kita tambahkan tidak merusak kode yang sudah ada atau menambah bugs yang baru sehingga aplikasi tetap berjalan sesuai dengan yang telah direncanakan. Prosesnya akan lebih cepat dan konsisten karena testing dilakukan oleh komputer dengan menjalankan script test yang ada. Namun tradeoff-nya adalah proses pengembangan yang lebih lama, karena selain menulis kode, developer juga perlu menulis test untuk kode tersebut. Namun hal ini sering dipandang sebagai investasi karena waktu yang diperlukan untuk menulis test jauh lebih sedikit jika dibandingkan dengan waktu yang dibutuhkan untuk mengecek bugs secara manual karena ketiadaan automated test.

Working Code Dulu, Test Kemudian

Oke, sekarang kita sudah mengerti mengapa kita memerlukan automated test dan mencoba untuk mengaplikasikannya. Alurnya adalah kita menulis kode dulu, setelah semuanya selesai baru kita menuliskan automated test-nya. Namun ada beberapa kelemahan yang muncul dengan metode ini :

  • Over-engineering : setelah menuliskan test, kita baru sadar kalau implementasi yang kita tulis lebih kompleks dari yang seharusnya.
  • Kode yang kita tulis sulit untuk di tes, membuat kita harus menyesuaikan kode yang telah kita buat agar dapat di tes oleh automated test.
  • No Test at All : Kita jadi malas untuk menulis automated test karena implementasi production code sudah selesai dan sudah berjalan dengan baik (untuk saat ini).

Jadi, sekarang kita balik metodenya — Test dulu, Working Code kemudian. Dan metode tersebut kita kenal dengan istilah Test Driven Development.

Apa itu Test Driven Development ?

Sesuai dengan namanya, Test Driven Development adalah pengembangan yang disetir oleh Test. Mudahnya, kita wajib menuliskan test terlebih dahulu baru production code. Implementasinya adalah sebagai berikut :

  1. Sebelum menulis kode, tuliskan test-nya terlebih dahulu. Pastikan kita memasukkan semua kemungkinan yang dapat kita pikirkan untuk input dan outputnya.
  2. Jalankan test-nya, dan pastikan test-nya fail karena belum ada kode apapun untuk membuat test-nya pass.
  3. Ketik working code seminimum mungkin dengan tujuan agar test-nya pass.
  4. Jalankan test dan cek apakah test-nya pass. Jika belum pass, maka perbaiki working code kita sampai memenuhi ekspektasi dari test.
  5. Merasa working code yang kita tulis tadi berantakan ? Jangan khawatir, Refactor the code, do some cleaning and DRY-ing. Selama test-nya masih pass, berarti tidak ada masalah dengan kode yang di refactor tersebut.
  6. Ulangi proses dari no 1–5 untuk fungsi-fungsi lainnya.
Image courtesy of http://www.agiletestingframework.com/atf/testing/test-driven-development-tdd/

Implementasi TDD Sederhana dengan PHP dan PHPUnit

Setelah mengerti konsep dari TDD, saatnya kita untuk melakukan implementasi agar lebih paham tentang praktek TDD di lapangan. Berikut adalah implementasi TDD sederhana dengan menggunakan PHP dan PHPUnit. Saya mengasumsikan teman-teman sudah menginstall composer di local machine dan versi PHP yang digunakan adalah 7.0.

  1. Buat 2 directory : src dan tests serta file composer.json

2. Install PHPUnit via composer. Isi file composer.json dengan snippet dibawah lalu jalankan perintah composer install.

Note: Jika kita ingin mengakses PHPUnit secara langsung di command-line, kita dapat menginstall PHPUnit secara global dengan cara memasukkan $HOME/.composer/vendor/bin ke dalam executable path di system environment (di Linux/ Unix biasanya di .bashrc atau .zshrc jika menggunakan ZSH). Lalu jalankan perintah composer global require phpunit/phpunit. Atau jika tidak ingin menginstall secara global, kita dapat mengakses PHPUnit dengan perintah ./vendor/phpunit/phpunit/phpunit FileTest.php

3. Setelah PHPUnit terinstall, kita bisa memulai praktek TDD. Aturan utama dari TDD adalah tidak ada production code tanpa diawali oleh test. Jadi kita buat test-nya terlebih dahulu. Kali ini kita akan menggunakan studi kasus sederhana yaitu Guest Book alias buku tamu. Buat file GuestBookTest.php di dalam folder tests. Untuk panduan penulisan test yang sesuai dengan PHPUnit, kita dapat melihatnya di sini.

Awalnya kita memanggil PHPUnit dengan meng-extends class dari PHPUnit. Setelah itu kita membuat fungsi tes sederhana untuk memastikan bahwa setiap tamu harus memiliki nama. Perhatikan dibagian $this->assertEquals(‘Wahyudi’, $result);, disinilah kita melakukan assertions atau mencocokkan apakah hasilnya sama dengan yang kita harapkan. Pada contoh diatas, kita berekspektasi bahwa variable result memiliki value Wahyudi.

Note : Untuk melihat tipe-tipe assertions apa yang dimiliki PHPUnit, kita bisa melihatnya di sini.

Selanjutnya, kita jalankan test tersebut. Dan sesuai dengan prinsip TDD, ketika menjalankan test untuk pertama kali, test tersebut harus gagal.

Yup, bisa kita lihat diatas error yang dihasilkan adalah Class Guest not found. Ini sesuai dengan harapan, karena pada saat test dijalankan, belum ada production code yang ditulis.

4. Selanjutnya, barulah kita menulis production code untuk membuat test tersebut pass. Kali ini kita buat file Guest.php di dalam folder src.

Lalu kita include file Guest.php di file GuestBookTest.php.

Dan kita jalankan lagi testnya.

Voila! Test-nya pass! Pada real cases, biasanya kita akan melakukan refactor pada production code untuk keperluan cleaning dan dry-ing. Dan sekali lagi, kita tidak perlu takut untuk me-refactor production code, karena jika perubahan kode membuat break atau muncul bugs baru yang menyebabkan hasil yang dikeluarkan tidak sesuai dengan yang direncanakan, anomali ini akan segera terdeteksi oleh test. Tentu dengan catatan, test dibuat secara komprehensif. Pada penerapan Continous Integration, test memegang peranan penting karena hasil kerja kita baru akan di-merge ke staging / production jika seluruh test-nya pass.

Setelah itu kita dapat maju ke fungsi berikutnya dengan mengulangi langkah-langkah diatas. Ingat konsep TDD berikut ini :

Fail - Pass - Refactor - Repeat

Selamat! karena teman-teman sudah selangkah lebih dekat dalam mengenal TDD 😎

Demikian sedikit gambaran tentang apa itu Test Driven Development. Di part selanjutnya kita akan lebih mendalami lagi tentang komponen-komponen dalam Test (Setup, Exercise, Verify, Teardown) dan juga bagaimana meng-handle data dari sumber luar seperti database atau third-party API di unit test dengan menggunakan Mocking. Jadi pastikan untuk melanjutkan membaca ke part 2 dan part 3. Happy TDD!

Terimakasih telah membaca artikel ini. Apabila anda menyukainya klik ❤️ dan share serta follow medium, facebook, atau twitter Koding Kala Weekend untuk mendapat info tentang artikel terbaru kami.

--

--

Wahyudi Wibowo
Koding Kala Weekend

Dad | Backend Dev : PHP, NodeJS, Go | Lifelong learner | Passionate about programming stuff