Setiap mengerjakan aplikasi dengan Java EE, gw selalu terbiasa menerapkan layer untuk

  • Model atau domain sistem seperti, User, Group, Departement, dsb tergantung ruang lingkup aplikasi
  • Data Access Object atau biasa disingkat DAO, untuk menenkapsulasi akses database terhadap domain sistem misalnya UserDao untuk operasi getAllUser(), findUserById(), saveUser(), deleteUser() dsb
  • Service layer untuk mengenkapsulasi berbagai macam Dao ke dalam satu service agar mudah digunakan dari sisi client (bagian lain dari aplikasi yang mengakses kode kita), misalnya UI atau antar muka
  • UI layer untuk logika2, validasi, dan flow yang bersifat interaksi dengan user

Concern gw adalah semakin banyak atau kompleks model atau domain sistem, biasanya Dao pun akan semakin banyak dan gw cenderung melakukan hal yang sama untuk hal2 kecil dan remeh, contohnya method untuk save user dan find user (menggunakan HibernateDaoSupport dari Spring),

[sourcecode language=’java’]
public class UserDaoHibernate extends HibernateDaoSupport implements UserDao {

public void save(User user){
getHibernateTemplate().saveOrUpdate(user);
getHibernateTemplate().flush();
}

public User findUser(Integer id){
final User user = (User) getHibernateTemplate().load(User.class, id);
getHibernateTemplate().initialize(user);
return user;
}

}[/sourcecode]
Kalo gw mau buat Dao untuk Group ya gw lakukan hal yang sama dengan mengubah User menjadi Group dan seterusnya. Ini jelas tidak mengikuti prinsipnya pragmatic programmer DRY (Dont Repeat Yourself), solusinya adalah dengan menggunakan konsep Generic dari Java 5, yang perlu gw lakukan cuma declare class GenericDao dan setiap Dao akan extends kelas ini. Kode diatas akan menjadi,
[sourcecode language=’java’]
public class UserDaoHibernate extends GenericDaoHibernate implements UserDao {
}[/sourcecode]
oh mau buat dao untuk group? gampang!
[sourcecode language=’java’]
public class GroupDaoHibernate extends GenericDaoHibernate implements GroupDao {
}[/sourcecode]
Konsep GenericDao ini sebenarnya sudah cukup lama dipulikasikan, namun karena sekarang lagi booming Spring 2.5, gw akan coba sharing GenericDao dengan Spring 2.5 + Hibernate dan meminimalisir jumlah konfigurasi yang ada di xml untuk dipindahkan ke source code. Gw ga bilang konfigurasi di xml itu jelek, tapi menurut gw ga semuanya harus ada di xml dan berikut ada post yang menarik mengenai konfigurasi dengan XML vs annotation. Anyway post ttg spring 2.5 juga dibahas oleh Endy Muhardin untuk akses ke DB dengan JDBC dan akses web.Langsung saja kita bahas ttg GenericDao dengan Spring 2.5 dan Hibernate,
Continue reading

Unit test menurut gw adalah hal yang wajib dilakukan oleh para developer modern, karena memang tidak ada alasan untuk tidak melakukan itu. Kenapa harus melakukan unit testing?

Unit test meningkatkan kualitas kode, semakin banyak kode seharusnya bug semakin sedikit. Pada fase bug fixing misalnya, prinsip “mati satu tumbuh seribu” ini hal yg lumrah jika tidak menggunakan unit test. Kualitas kode ini dapat kita peroleh karena dengan unit test akan mudah melakukan refactoring dan penambahan fitur, kenapa? karena developer bisa confident bahwa perubahan atau penambahan fitur yang dilakukan tidak berdampak terhadap modul lain. Dengan prinsip Test Driven Development, yaitu menulis test dulu baru membuat implementasi kode, membuat setiap unit terkecil (method) dari kode akan mempunyai unit test. Sehingga ketika kode sudah banyak -unit testnya juga banyak- dan pada saat developer melakukan perubahan di satu tempat, dia akan yakin apakah test2 yang sebelumnya sukses atau gagal. Dan kalopun gagal, bugnya lgsng ketahuan -tidak pada saat testing atau UAT :P- . Hal ini tentu berdampak pada cepatnya development cycle. Walopun saya setuju pada saat awal2 akan terasa lambat kodingnya tapi ini investasi yang besar seiring bertambahnya kode aplikasi.

Menurut, andrew hunt pengarang pragmatic unit testing untuk membuat unit test yang baik harus memenuhi prinsip2 utama (A-TRIP):

  • Automatic, testing harus otomatis, setiap kali perubahan developer lgsng tahu apakah kode perubahan tsb error atau impact ke modul lain.
  • Through, testing harus mencakup seluruh kode aplikasi.
  • Repeatable, diulang berapa kali pun hasilnya tetap sama
  • Independent, tidak bergantung ke objek atau modul lain
  • Professional, menulis test harus sama bagusnya dengan menulis kode.

Pada kali ini gw akan bahas syarat yang ke empat yaitu Independent. lalu bagaimana menghilangkan dependensi terhadap objek2 lain dengan mock object. Sebenarnya ada hal2 lain kenapa harus me-mock (memalsukan) objek dalam unit test.Continue reading