gonz0′s Blog

Well, had this site quite abandoned lately… this is certainly a good way of reviving it.

I just got out of my certification exam, and successfully passed it. I’m now a Spring Certified professional, after having taken the course a while ago and finally raised some courage to appointing for the test.

I cannot give that much feedback regarding the exam, as stated by the certification policy. But I’d encourage any SpringAwareDeveloper to take it after using Spring for a while.

The test took place at IT College, the same venue where the course was. The examination room was a single computer room, where it was me alone with the computer. I expected something different because of the documentation I had read, but no complains anyways.

What sort of disappointed me was the “certificate” I was awarded with. I do hope to get something more official than a black and white printout of the exam results. I’ll post back then

Enough for now. Back to work!

I’ll be attending SpringSource‘s Spring Core training this week. Two cool remarks from day one:

Infrastructure beans in its own bean definition file

After having heard this suggestion, I can’t believe I didn’t think of it before. Having plumbing beans on a separate file makes all the sense in the world. It is expected to change for different environments, so data sources for instance can be defined as pools or JNDI lookups for a web environment, and as stub beans for testing.
Building an application context then means having to specify more than one configuration file. No big deal, and much to gain!

EasyMock

Ok, this is not Spring related, I’ll give you that. But I discovered it during the training. I loved it. Basically it does all the stubbing I’ve ever done for testing in a way that is so simple… the disadvantage mentioned in the course was that it’s difficult to understand. I disagree so much! What can be easier than this?

 // first, create a mock for a dependant interface.
 Interface mocked = EasyMock.createMock(Interface.class);
 // "inject" it.
 testedClass.setDependency(mocked);
 // notify EasyMock of expected calls. You can also define return values!
 EasyMock.expect(mocked.someCallDoneInsideTestedMethod());
 // indicates that the mocked object is configured and can start tracking calls.
 EasyMock.replay(mocked);

 // the actual test involving a call to the mocked interface.
 testedClass.testedMethod();

 // check that the call was actually done.
 EasyMock.verify(mocked);

Without further ado, I give to you EasyMock!

Tomorrow, it’ll be all about AOP with Spring. Stay tuned!