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 ?

Banyak orang yg salah mengartikan makna kata test pada TDD. Memang dengan test kita bisa memastikan code dapat berjalan. Tapi kalau misalnya kita tidak dapat menjelaskan dengan tepat behaviour apa yg seharusnya berjalan maka hal tersebut bisa membawa kebingungan. Yang mana yg benar. Jalan tapi tidak tau itu benar atau salah. Nah jadi kita bisa menggantikan kata test dengan kata behaviour. Anda akan merasakan perbedaannya.

Jadi jika kita ingin memberi nama test kita.. Yah tinggal pikirkan aja kalimat yg dapat menjelaskan behaviour seperti apa yg kita akan buat. Contohnya behaviourFailedIfPasswordWrong atau behaviourSuccessInLoginValid atau shouldSaveInvoiceItemSucessfully dll. Dengan memberi nama berikut kita sudah membatasi apa yg akan kita test. Dan jika ada test yg gagal maka kita dapat menyelidiki dimana masalahnya.

Jadi sekarang kita bergerak dari TDD ke BDD. Test ke Behaviour.

Jadi ketimbang memberi nama CustomerLookupTest kita akan memberi nama CustomerLookupBehaviour. Behaviour apa saja yg mungkin terjadi di CustomerLookup. COntoh  shouldReturnAnExistingCustomerWithGivenValidId. Ga masalah dengan panjang. Yg penting jelas. Jadi ga ada masalah dengan extra typing. ketimbang ntar jadi extra pusing. hehehe.

BDD juga dapat membantu kita dalam menentukan fitur apa yg selanjutnya akan kita buat. Business Value. Memang kita selalu membuat code berdasarkan tujuan bukan ? tapi kadang kita ga ngerti dan kadang ga kepikiran nilai dari code yg sedang kita buat. apa maknanya. tujuannya pa. seperti mayat hidup saja. hahahaa

Jadi sebelum membuat code fokuslah terlebih dahulu pada pertanyaan : Apa lagi hal penting yg belum dilakukan sistem ini ? dan buatlah test berdasarkan itu dan lakukanlah TDD.  Jadi kombinasikanlah.

Dengan pertanyaan itu kita dapat mengidentifikasi fitur2 yg blum diimplementasikan dan memberikan prioritas. Yaps. Mulai nyambung dengan TDD yg mewajibkan bikin list test dan prioritas. eh… udh ganti jadi list behaviour. Jadi dari pertanyaan itu kita bisa buat nama method. System belum dapat melakukan hal bla bla. Dimana bla bla adalah behaviour yg penting. Maka system seharusnya dapat melakukan bla bla. Nama method behaviournya adalah …

public void shouldDoBlaBla() {
    // ...
}

Advertisement