Behaviour Driven Development (Part 2)

Nama test yg jelas sangat membantu jika test tersebut error. Ketika kita melakukan perubahan dan test yg sebelumnya berhasil gagal, maka kita dapat mengeceknya dari nama methodnya. Apa sebenarnya behaviour yg diinginkan dari test tersebut. Biasanya salah satu dari berikut yg terjadi …

1. Ada bug baru. Solusinya perbaiki bugnya
2. Behaviournya masih relevan tetapi sudah berpindah ke tempat lain. Solusinya pindahkan test tersebut ke tempat yg semestinya dan mungkin mengubahnya.
3. Behaviournya sudah tidak sesuai lagi. Karena system sudah berubah.  Perubahan requirement. Solusinya : delete test tersebut.

Pilihan yg terakhir itu biasanya kita ga percaya diri melakukannya. Karena kita takut kualitas code menjadi berkurang. Tapi sebenarnya itu alasanya kita menggunakan kata should (seharusnya). Jadi ketika kita lihat test tersebut kita bisa mengujinya dngan kata really (benarkah). Benarkah seperti itu ?? atau sekarang sudah tidak lagi. Jadi ketika test tersebut gagal kita bisa menguji kembali dengan kata benarkah harus seperti itu ?

Advertisement

Behaviour Driven Development (Part 1)

ketika pertama kali diperkenalkan metode TDD (test driven development) kebanyakan orang bingung apa yg mau di test, dari mana mulainya, seberapa banyak yg harus ditest, apa nama testnya, bagaimana mengerti kenapa testnya gagal. Muncul banyak pertanyaan yg membuat jadi sulit mengetest. Wajar aja sih. Karena emang object yg mw di test blum ada.

Nah bagaimana mengatasi masalah tersebut. Jawabannya adalah BDD alias Behaviour Driven Development. Walah. Blum mahir TDD udh nambah lagi dengan BDD. Ga masalah. Karena keduanya saling melengkapi.

Nah apa2 practice yg ada di BDD. Kita mulai satu persatu.