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 Link to heading
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 Link to heading
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.