TDD Adalah

Dicky Eka Satria
3 min readApr 18, 2017

--

Test-driven development (TDD) adalah proses pengembangan perangkat lunak yang bergantung pada pengulangan siklus pengembangan yang sangat singkat. Persyaratan untuk melakukan sebuah perubahan menjadi kasus uji yang sangat spesifik, maka software yang sedang dikembangkan diharuskan memenuhi test baru. Hal ini bertentangan dengan pengembangan perangkat lunak yang memungkinkan perangkat lunak untuk ditambahkan belum tentu memenuhi persyaratan. Pada proses software development ada beberapa proses yang pasti dilakukan, sehingga terbentuklah iterasi suatu langkah — langkah yang mungkin sudah lazim dilakukan.

Gagasan ide untuk metode ini dipublikasi oleh seorang Software Engineering dari United States (US) bernama ‘Kent Beck’. Pada awalnya, tahun 1976, terdapat publikasi dari ‘Glenform Myers’ dengan judul “Software Reliability” yang berisi tentang keseringan para developer tidak pernah melakukan ujicoba dari code sendiri. Lalu pada tahun 1991, pembuatan sendiri ujicoba pada framework Taligent” yang hampir mirip dengan SUnit. Pada tahun 1994, ‘Kent Beck’ menulis proses ujicoba SUnit pada framework SmallTalk’. Kemudian pada tahun 1998, muncul sebuah berita yang berjudul “we usually write the test first”. Lalu mulai tahun 1998 sampai 2002, teori “Test First” diuraikan ke dalam “Test Driven” melalui artikel di website C2.com. Lalu pada tahun 2000, metode tersebut dikembangkan pada saat itu. Kemudian pada tahun 2003, ‘Kent Beck’ mempublikasinya dengan judul “Test Driven Development: By Example”. Dan pada akhirnya tahun 2006, metode TDD yang telah dikembangkan dengan baik mulai mendorong inovasi lebih lanjut seperti metode Acceptance Test Driven Development (ATDD) & Behavior Driven Development (BDD).

Pada metode ini, ada beberapa yang akan dilakukan oleh para software enginer, yaitu :

1. Menambahkan ujicoba (Add a test)

2. Menjalankan semua ujicoba dan melihat hasil baru ujicoba (Run all tests and see if the new test fails)

3. Menulis code (Write the Code)

4. Menjalankan ujicoba (Run tests)

5. Melakukan pembersihan pada code (Refactor Code)

6. Melakukan proses di point 1–5 secara berungkali sesuai fungsi yang diharapkan (repeat).

Berikut ini gambar dari alur metode Test Driver Development (TDD) :

Gambar 2.2. Flow Test-Driven Development

Dari gambar 2.2, kita bisa lihat bahwa proses di mulai dengan “add test”, proses dimana developer akan menulis skenario ujicoba dari code yang akan dibuat. Lalu proses selanjutnya yaitu “execute the tests”, proses ini diperlukan untuk menjalankan semua ujicoba dari code yang akan di buat, jika hasilnya “pass” maka bisa kembali ke proses sebelumnya, namun jika hasil dari proses ini “fail”, maka developer akan melakukan proses selanjutnya yaitu “Make Changes to The Code”. Proses ini dilakukan dengan cara merubah code sesuai dengan skenario ujicoba yang telah di buat di awal proses. Kemudian dilanjutkan dengan proses “Execute a tests”, proses ini sama dengan proses setelah “Add Test”, yaitu proses dimana semua ujicoba di jalankan untuk mengetahui hasil dari ujicoba nya. Jika hasil didapatkan “fail” maka kembali proses selanjutnya yaitu “Make Changes to The Code”. Jika “pass” maka akan kembali ke awal dari proses yaitu “Add Test”, dan jika proses ini dilakukan berulang kali sesuai code dapat memenuhi kebutuhan dari customer.

Gambar 2.3. Global Cycle Test-Driven Development

Pada gambar 2.3, Hal ini bertentangan dengan pengembangan perangkat lunak yang memungkinkan perangkat lunak untuk ditambahkan belum tentu memenuhi persyaratan[2].

Ada beberapa bagian dari proses ujicoba pada metode ini, yaitu :

1. Kebenaran dalam memasukkan data

2. Kesalahan pada pemasukan data

3. Beberapa kesalahan yang sering muncul

4. Pengecekan batas maksimal

5. Sesuatu yang kemungkinan dapat dilanggar

Dari penjelasan diatas, pada metode Test-Driver Development (TDD), ada beberapa hasil dari penggunaan metode ini, berikut :

1. Waktu yang dipergunakan untuk proses debug akan lebih singkat / sedikit

2. Source code yang dihasilkan terbukti memenuhi persyaratan

3. Ujicoba dari source code bisa menjadi landasan keamanan

4. Didapatkan hasil mendekati 0 kecacatan

5. Perputaran software development yang lebih pendek

--

--