Mockito is first mock framework you should consider

Having been stuck on jdk 1.4 for the last 3 years it came as something akin to a coming of age to step into modern java; and a most satisfying revelation has been mockito.

If you have used easy mock in the past you will be very pleased and probably quite excited when you encounter and start using mockito. It is totally awesome.

It is simple, intuitive, terse and has some very powerful features. It will gracefully handle almost all of your mocking needs. For example, it is possible to stub out selected methods on a live object.

To give you an example of mockito in action, to whet your appetite, here is a code snippet.

ConfigParams params = Mockito.mock(ConfigParams.class);
when(params.getInt(ConfigParamKey.AGENT_MATCH_TIMEOUT)).thenReturn(99);

So, it's fairly self explanatory, when the method getInt is called with the parameter ConfigParamKey.AGENT_MATCH_TIMEOUT then the mock should return 99.

In case you were wondering how this all happens, generics are playing an important role - thus the reason why it is only available on jdk5+

As in EasyMock and JMock you can verify that the method was called.

It is probably worth pointing out that Mockito tries to be less strict with its mocking than other mock frameworks. For example, the default mock you get will accept any call - and unless you specifically verify (which you can do), not calling the method will not cause a test failure.call

See the web site for more information, downloads and demos.

Best Practices are for people who don't know what they're doing

On my last project, I can remember occasionally reading through "best practices" of the various technologies we were using. Spring and hibernate spring to mind.

I can remember noting that we were not following a large number of the best practices. In fact, what is more interesting is that we had made those decisions without considering the so called "best practices".

However we did not make those decisions without considering all the variables. In each instance where we diverted from the best practice we did so for good reason and with our eyes open. In other words, we did not deviate from best practices because we were rebellious but because we knew what we were doing. In all cases we had a ready defense for not using the best practice.

I realised in doing this that the point of best practices is to protect the person who does not quite understand what they're doing, to make sure they don't really shoot themselves in the foot. For those people who understand the situation, best practices are useful because they provide a base to work from. If you deviate from best practices make sure you can defend your deviance.

Furthermore, I'd also like to add, that very often a so called best practice is someone's opinion. A few months ago I wrote on what I thought were hibernate "best practices". These are based on my experience and my opinion, they are my best practices not necessarily industry tried and tested best practices. So the label "best practice" is often a fairly loose term.

Best practices are for people who don't know what they're doing, but for people that do, the tried and tested ones are a good and worthy starting point that should only be deviated from for good reason.

Spring with annotations - in 2 minutes

I have just recently, today, had my first look at spring with annotations. Up until now I have always had to use spring on VM 1.4 so was unable to take advantage of annotations.

Suffice to say, it is awesome!

Now I know for a lot of you, this might be old news, but it wasn't for me.

So you remember the old xml based spring configuration...

<bean id="serviceLayer" class="za.co.bbd.ct.ServiceLayer">
<property name="businessObject" ref="businessObject">
<property name="xmlConfigured" ref="xmlConfiguredX">
</property>

When using annotations, no nasty xml is required.

@Component

public class ServiceLayer {

private IBusinessObject businessObject;

private IXmlConfigured xmlConfigured;

@Resource(name = "businessObject")

public void setBusinessObject(IBusinessObject businessObject) {

this.businessObject = businessObject;

}

@Resource(name = "xmlConfiguredX")

public void setXmlConfigured(IXmlConfigured xmlConfigured) {

this.xmlConfigured = xmlConfigured;

}

}

Then in your spring xml file the following is required. The good thing is that you can mix annotation and xml based configurations seamlessly.

<!-- tell spring to use annotation based congfigurations -->
<context:annotation-config />

<!-- tell spring where to find the beans -->
<context:component-scan base-package="za.co.bbd.ct" />

The default name for the bean is the class name without the package name in camel case, iow that "businessObject" class has this as its annotation:

@Component

public class BusinessObject implements IBusinessObject {

}

And if you'd rather not specify the name of the reference and just match by type:

@Autowired

public void setBusinessObject(IBusinessObject businessObject) {

this.businessObject = businessObject;

}

You can mix xml and annotation based configurations. The definition for xmlConfiguredX is also in the xml...

On a project I was on we used xdoclet to circumvent the lack of annotations (project was on 1.4). We had 100K's worth of generated xml spring configuration files. Annotations would have been so much better!

You don't know what you don't know...

When I started on my last project, a very large enterprise application I did not know too much. I had not done enterprise programming before, I had not used web services nor had I used hibernate, all of which were used to the fullest on the project.

When I arrived, we spent six weeks finding out what challenges lay ahead, where we would have problems and on their solutions...

Turned out that zero of what we did during that time was useful.

Problem was, we did not know what we did not know. Sounds like a redundant statement but it's not. IOW we did not know where the holes in our knowledge was. We did not know web services enough to realise that we were going to have problems interfacing via web services between dotnet and Websphere. We did not know hibernate enough to know that using inheritance and putting sub types into collection was going to be problematic. We did not know that we would have to work very hard figuring out the issues with JNDI and session beans.

We wasted a lot of time because of this. We should have got someone in, not to help us with the problems, but simply to tell us where the problems were going to be. We had the ability to solve the problems, we proved that as we solved them, what we didn't have was the knowledge to know where the problems were going to be.