Tuesday, September 16, 2003

My work on OTN
Check out Virtual Shopping Mall 1.3 - A sample app with an aim to demonstrate end-to-end J2EE application architecture.
Has EJBs,JSPs, i18n ,Struts,JAAS etc.
Unit test blues with CRUD methods on RDBMS
I had a small discussion with Rajesh Babu about unit testing methods that involve CRUD on Database. There does not seem to be an obvious way to manage test fixtures and initial conditions for tests.
For example, i need to test a method create(), which inserts a record to database.So i write a JUnit testcase for this.
...
create(myObject);
Okay, now the assertion part.To ensure that the values inserted are indeed the ones supplied, I have to read them from DB and assert that they are correct. This test code gets complicated. Also, there is a lot of execution overhead in setUp() tearDown() methods of JUnit, since I have to set up and clean data in database for each set of test cases.
Though I wrote a simple set of classes which make use of property files to associate data with test cases and feed the data to test cases, the database problem remains unsolved.
Rajesh suggested using mock objects, but the first try proved too complicated to maintain them.There were too many mock objects representing the database.
Will ponder upon this and post any findings
Static or not?
Me and my collegue were having a discussion on static methods in Java. My collegues argument for static methods went this way
* They are fast [because of compile time binding]
* No need to instantiate classes, makes memory conservation
And my sole point against static methods
* No flexibility , if you want to change behaviour of the class partly,can't override .
I think only when absolutely convinced that the methods are NOT going to change, should one use static methods. A good example quoted by everyone is Math class. abs() is always abs().
If I need subclassing, changing method behaviour I would settle for nonstatic methods.