Archive for November, 2008

Hubungan TDD dengan Objects
November 3, 2008

Jejaring Object

Pemprograman berorentasi object adalah teknik membuat program dengan object sebagai titik-titik perhatian. Object pada umumnya adalah wakil dari sebuah benda atau keadaan dalam sebuah sistem sesungguhnya. Namun demikian, fokus utama dari ‘berorentasi object” adalah komunikasi antar object bukan pada diri object.

Sebuah object dalam berkomunikasi menerima pesan dari object lain dan kemudian menjawab pesan itu dengan memberikan pesan pada object lain atau mengembalikan sebuah nilai atau malah mungkin pesan error pada object pengirim pesan. Kirim mengirim pesan ini dalam sebuah object diwakili oleh perintah yang diberinama “Method”. Didalam method inilah pesan kemudian diterjemahkan, state diubah, pesan ke object lain dipanggil dan lain sebagainya.

Dalam sebuah system berorentasi object, object-object tersusun dan terhubung seperti jaring, sedemikian hingga object-object saling bisa berkomunikasi. Perilaku dari system seperti ini tergantung pada pilihan object yang disusun. Sekali seubah object didalam sistem diganti, maka perilaku dari sistem itu juga berubah.

Jejaring Objects

Jejaring Objects

Gambar. Jejaring Object

Karena perilaku dari sebuah sistem dapat kita ubah-ubah hanya dengan mengganti object, dengan demikian untuk mengatur object-object kita cukup mendeklarasikan saja. Artinya kita hanya fokus pada apa yang akan dilakukan object bukan pada bagaimana sebuah pesan dikerjakan.

Tell Don’t Ask

Ok. Object-object sekarang sudah saling terhubung, bagaimana sih sesungguhnya mereka berkomunikasi? Dalam berkomunikasi object akan mendeskrispsikan apa yang diinginkannya pada object lain, tentu saja sesuai dengan aturan dari object lain itu. Sesuai tugasnya object lain tersebut kemudian melaksanakan apa yang diperintahkan.

Alec Sharp dalam bukunya Smalltalk by Example, mengatakan:

Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.
— Alec Sharp

Cara berkomunikasi seperti ini umumnya disebut sebagai model “tell don’t ask”, yang merupakan hukum Demeter. Tell berarti object memerintahkan object lain untuk melakukan sesuatu–sesuai rule-nya tentu. Sedangkan ask berarti object meminta state object lain dan berdasarkan state itu object memutuskan sesuatu terhadap object lain. Maksudnya, daripada mengquery state sebuah object, yang bisa jadi nanti malah kehilangan makna, lebih baik langsung memerintahkan object lain itu. Biarkan object lain memutuskan sendiri apa yang harus dilakukan berdasarkan state yang dia punyai.

Berdasarkan hukum Demeter, method dalam sebuah object hanya boleh memanggil hal-hal yang dimiliki oleh:

  • object itu sendiri.
  • parameter-parameter yang dikirim melalui method tersebut.
  • object-object yang dicreate oleh object itu sendiri.
  • komposisi object.

Mengikuti hukum ini, perubahan terhadap sebuah object tidak akan mempengaruhi object lain, dengan demikian tercapailah tujuan agar memanage object-object itu cukup dengan “declaratif”. Jadi hukum ini akan membuat object-object tidak saling tergantung.

Nat dan Steve memberikan contoh dalam bukunya, Growing Object-Oriented Software, Guided by Tests,
mengenai apa yang akan terjadi jika kita tidak mengikuti hukum ini, mereka menyebutnya “train wreck code“, kereta yang celaka:

((EditSaveCustomizer) master.getModelisable()
  .getDockablePanel()
    .getCustomizer())
      .getSaveItem().setEnabled(Boolean.FALSE.booleanValue());

Setelah dipikir sejenak mengikuti hukum Demeter, maka code ini seharusnya:

master.allowSavingOfCustomisations();

Jadi pemanggilan yang mirip rangkain kereta itu cukup diwrap dalam satu method yang bisa dimengerti saja. Sebagai pengguna object master, kita tidak perlu tahu apa yang diperbuat oleh object master.

Tentu, tidak semua kita “tell” ada beberapa hal yang tetep harus kita “ask”, seperti jika kita berhubungan dengan Value Object, Collection, dan juga dataset.

Object Unit Testing

Mengisolasi Object

Lantas bagaimana melakukan unit test agar state dari sebuah object tidak terekspose keluar? Pertama-tama object harus kita isolasi. Kembali pada gambar yang dibuat oleh Nat dan Steve, object in isolation, salah satu object, yang dilingkari merah, menerima pesan dari dua object dan megirim pesan ke tiga object disekitarnya. Kelima object penerima dan pengirim pesan akan kita singkirkan dan tinggallah satu object dalam lingkaran merah.

how to test one object

how to test one object

menjadi,

Mock Objects.

Mock Objects

Kalau kawan-kawannya kita singkirkan, lalu kawan-kawannya kita ganti dengan apa? Kita akan ganti dengan mock atau stub atau apalah yang jelas bukan object sebenarnya. Pada saat melakukan test class-class pembentuk object sebenarnya juga tidak harus ada, cukup diwakili oleh sebuah interface yang menggambarkan apa tugas object yang diwakilinya. Dengan cara seperti ini sebetulnya pada saat yang sama kita juga sedang mencari bentuk object seperti apa yang bisa  mewakili.—lebih jauh kita akan bahas dengan sebuah contoh(MVC Calculator).

Mocking Object

Lantas jika object-object disekitarnya tidak ada, bagaimana kolaborasi itu bisa dilaksanakan? Caranya adalah dengan mengganti object-object tadi dengan object Mock. Apa yang dikerjakan Mock? Sebagai wakil dari object sesungguhnya, Mock akan mengeluarkan kemampuan yang  diinginkan test atau disebut Expectation. Jadi setiap kali sebuah object yang kita test membutuhkan respon dari object lain, maka kita tambahkan Expectation didalam Mock. Sekali lagi saya gunakan gambar Nat dan Steve:

Mockery adalah factory dari object-object yang kita mock. Apa yang kita mock? Yang kita mock adalah interface.

Berikut ini adalah langkah-langkah membuat test (khusus untuk object-object yang sudah jelas):

  1. Mock semua object yang dibutuhkan (object-object disekitar).
  2. Buat object yang akan ditest (kongkrit object).
  3. Setup semua Expectation yang diinginkan.
  4. Triger event dari object yang ditest.
  5. Uji semua yang hendak ditest dan cek semua ekspektasi telah dipenuhi.

Ini adalah urutan jika kita sudah tahu semua yang terlibat. Jika belum, saya biasanya bergerak dari bawah keatas (5–>4–>3–>2–>1).

Kita akan bahas lebih lanjut mengenai mock dengan contoh.