Mengapa TDD? Karena feedbacknya

Salah satu keuntungan terbesar yang saya rasakan dari menerapkan Test Driven Development adalah “feedback-loop” yang singkat.

Feedback untuk apa?

Yang paling utama adalah feedback untuk rancangan sistem yang kita buat.

TDD tidak hanya berbicara soal test yang kita buat sebelum kode kita tulis. Namun ia juga mendorong kita untuk berfikir tentang karakteristik dari perilaku (behaviour) yang mau kita terapkan.

Pada dasarnya, kita harus merancang sistem sebelum menuliskan test. Mengutip Uncle Bob:

Any design that is hard to test is crap. Pure crap. Why? Because if it’s hard to test, you aren’t going to test it well enough. And if you don’t test it well enough, it’s not going to work when you need it to work. And if it doesn’t work when you need it to work the design is crap. Sumber

Rancangan sistem juga tidak sekedar berbicara soal implementasi kode. Tetapi ia juga berbicara tentang kebutuhan bisnis terhadap kode yang akan kita tuliskan. Mengapa?

Salah satu pendekatan yang sangat membantu dalam penulisan TDD adalah membuat test untuk suatu perilaku tertentu, bukan object tertentu.

Jadi, daripada menuliskan ShoppingCartTest, kita menuliskan BuyingMultipleItemsTest. Ketika menggunakan pendekatan ini, maka kita didorong untuk berfikir tentang alur “membeli lebih dari satu barang”.

Kebutuhan di atas mendorong developer untuk mengenali “business domain”. Disini kita bisa belajar menggunakan “ubiquitous language”, dimana developer menggunakan & memiliki pemahaman yang sama dengan istilah yang digunakan oleh “domain experts”.

Proses di atas juga adalah satu satu cara memperoleh feedback. Apakah saya sebagai developer memahami requirements? Hasil nyata dari proses ini adalah “acceptance scenario”. Tidak jauh dari “examples” yang digunakan oleh para praktisi BDD (Behaviour Driven Development”). Contoh kasar:

Sebagai developer,
Ketika saya sudah duduk selama 30 menit,
Maka saya diminta untuk berjalan-jalan sebentar.

Yay… kita punya 1 skenario untuk ditest.

Ok, kita sudah membahas 2 feedback yang dapat kita peroleh dari penerapan TDD: design feedback & domain feedbacks. Ada feedback apa lagi?

Kita bisa memperoleh feedback apakah kode baru / perubahan yang kita buat masih sesuai dengan desain & requirements yang sudah disepakati sebelumnya.

Perubahan adalah hal yang pasti dihadapi oleh sebuah sistem. Rugi sekali bila kita menghabiskan waktu untuk melakukan testing manual demi memastikan bahwa perubahan yang kita buat tidak merusak sistem.

Inilah alasan mengapa sampai saat ini, TDD adalah investasi yang tidak pernah saya sesali.

Apakah Anda menerapkan TDD juga? Untuk alasan apa?


Salah satu contoh bagaimana TDD memberi feedback terhadap desain yang saya buat: https://medium.com/@keripix/bagaimana-test-membantu-saya-mendesain-objek-ad7c27cf1717