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.

Gunakanlah kalimat sebagai nama method test.

[TestFixture]
public class CustomerLookupTest {
   [Test]
   TestFindsCustomerById() {
      ...
   }
   [Test]
   TestFailsForDuplicateCustomers() {
      ...
   }
   ...
}

nah jika kita mengambil nama setiap test dan membentuknya sebagai kalimat maka akan terlihat seperti ini.

CustomerLookup
– finds customer by id
– fails for duplicate customers
– …

Hasil format di atas dapat dijadikan sebagai dokumentasi. developer membuat test sebagai dokumentasi mengenai apa2 saja yg dapat dilakukan oleh kelas. jadi untuk memperjelas maka nama test tersebut haruslah merupakan kalimat yg jelas. Dan yg bukan programmer saja yg akan mengerti jika membaca dokumentasi yg di generate diatas. Tetapi juga analyst, user. Jadi pilihlah nama method yg memang benar2 berasal dari domain. Hal ini berhubungan juga dengan Ubiquitous Language dari DDD.

Konvensi memulai nama method dengan “should” juga membantu kita berfokus pada kelas yg sedang ditest. The class “should” do something. Kita berharap dengan menjalankan test tersebut maka objectnya akan bertingkah laku sesuai dengan yg kita inginkan (nama method). Tingkah laku = behaviour. Nah sudah menjadi semakin jelas. Jadi memulai dengan should membuat kita tetap fokus. Jika kita menuliskan nama test yg tidak lulus atau tidak cocok dengan “the class should do bla bla” berarti behaviour tersebut bukan merupakan milik dari kelas tersebut. Jadi selalulah test dengan template “the class should do” dalam membuat nama method test. Sehingga tidak terjadi kesalahan responsibility.

Contohnya. Kita sedang membuat kelas untuk melakukan validasi terhadap inputan user dari UI. Field2nya adalah forename, surename , dll. Juga ada field untuk umur dan tanggal lahir. Nah kita mulai dengan membuat nama class testnya. ClientDetailsValidatorTest. dengan method TestShouldFailForMissingSurname dan TestShouldFailForMissingTitle.

Nah kemudian kita membuat test untuk mengecek umur. Banyak yg harus dicek. Bagaimana jika kedua field (umur dan tanggal lahir) tersebut diisi ? maka keduanya haruslah sesuai. . Bagaimana jika ulang tahunnya skarang ? Bagaimana jika hanya tanggal lahir yg disediakan ?

Nah dengan membuat nama test TestCalculateAge. Loh ini sepertinya ga nyambung dengan behaviour ClientDetailsValidator. Coba kita lakukan test dengan template “the class should do bla bla”. Class ClientDetailsValidator should do Calculate Age. Wah .. ga nyambung. Seharusnya hal itu dilakukan oleh kelas lain. Nah kita harus membuat kelas kalkulator untuk menghitung Umur. Kita beri nama AgeCalculator dan nama testnya AgeCalculatorTest. Nah jadi semua kalkulasi yg berhubungan dengan Age dilakukan di AgeCalculator. Dari ClientsDetailsValidator tinggal minta hasil dari AgeCalculator.

Jika kelas kelihatannya mencoba melakukan banyak hal, maka itu pertanda kita harus membuat kelas baru. Satu kelas hanya boleh memilki satu responsibility. Nah sekarang kita punya service baru yaitu AgeCalculator. Kita tinggal lewatkan dari constructor saja.

public class ClientDetailsValidator {

   AgeCalculator ageCalc;

   public ClientDetailsValidator(AgeCalculator ageCalc) {
      this.ageCalc = ageCalc;
   }
}

Nah kita bisa menginjectnya (Dependency Injection) dari constructor untuk menghubungkan kedua object tersebut.

Advertisement