Tuesday, 29 November 2011

Any one who reads this blog will probably have realised that at present I’m working on a project that contains a whole bunch of legacy code that’s large, expansive, and written without any tests what so ever. In working with this legacy code, there’s been one very badly behaved class that’s all pervasive, which the whole team have tripped over time and time again. In order to protect the guilty, I’ll call it Mr. X although its real name is SitePropertiesManager as it manages the web site’s properties.

Thursday, 24 November 2011

My last blog was the fourth in a series of blogs on approaches to testing code, demonstrating how to create a unit test that isolates the object under test using a stub object. Today’s blog looks at what is sometimes regarded as an opposing technique: unit testing with mock objects. Again, I’m using my simple scenario of retrieving an address from a database:

Tuesday, 22 November 2011

My last blog was the third in a series of blogs on approaches to testing code and discussing what you do and don’t have to test. It’s based around my simple scenario of retrieving an address from a database using a very common pattern:

...and I proffered the idea that any class that doesn’t contain any logic doesn’t really need unit testing. In this I included my data access object, DAO, preferring instead to integration test this class to ensure it worked in collaboration with the database.

Friday, 18 November 2011

I was in the office yesterday, talking about testing to one of my colleagues who was a little unconvinced by writing unit tests. One of the reasons that he was using was that some tests seem meaningless, which brings me on the the subject of what exactly you unit test, and what you don’t need to bother with.

Consider a simple immutable Name bean below with a constructor and a bunch of getters. In this example I’m going to let the code speak for itself as I hope that it’s obvious that any testing would be pointless.

Monday, 14 November 2011

There’s not much doubt about it, the way you test your code is a contentious issue. Different test techniques find favour with different developers for varying reasons including corporate culture, experience and general psychological outlook. For example, you may prefer writing classic unit tests that test an object’s behaviour in isolation by examining return values; you may favour classic stubs, or fake objects; or you may like using mock objects to mock roles, or even using mock objects as stubs. This and my next few blogs takes part of a very, very common design pattern and examines different approaches you could take in testing it.

Friday, 11 November 2011

I perhaps shouldn’t mention this, but one of my colleagues sent around an email pointing to a very cool video made, I suspect, by a competitor, and saying how good it was. At about a minute or two in, they showed some code and bragged at about their digital services. So, as a diverting interlude, I did a tongue-in-cheek critic of the code in a screen shot....

Wednesday, 9 November 2011

When you write a blog, you get a feel for those subjects that are contentious and those that aren’t and one of the most contentious subjects seems to be the area of unit test techniques: are you a mockist or a classist? Can you test internal state or private methods? Should you just test behaviour? Just out of curiosity, I recently took a look at Powermock, software with which I have no relationship, and I wrote four simple ‘how to’ blogs on some of its features. The blogs were:

One of the things I didn’t do was to sum up how useful I thought each of the features were, which led to some constructive criticism, which I broadly agreed with before the authors made their first keystrokes.

Monday, 7 November 2011

Once you’ve got your Maven project built and sorted, one of the neat tricks you can do to make it look even more professional is to add a Maven Site. Maven gives you the ability to add a whole site structure with one simple command.

Friday, 4 November 2011

JSR-250 aka Common Annotations for the Java Platform was introduced as part of Java EE 5 an is usually used to annotated EJB3s. What’s not so well known is that Spring has supported three of the annotations since version 2.5. The annotations supported are:

@PostContruct - This annotation is applied to a method to indicate that it should be invoked after all dependency injection is complete.

@PreDestroy - This is applied to a method to indicate that it should be invoked before the bean is removed from the Spring context, i.e. just before it’s destroyed.

@Resource - This duplicates the functionality of @Autowired combined with @Qualifier as you get the additional benefit of being able to name which bean you’re injecting, without the need for two annotations.

Wednesday, 2 November 2011

The @ModelAttribute annotation is used as part of a Spring MVC web app and can be used in two scenarios.

Firstly, it can be used to inject data objects the model before a JSP loads. This makes it particularly useful in ensuring that a JSP has all the data is needs to display itself. The injection is achieved by binding a method return value to the model.

Secondly, it can be used to read data from an existing model assigning it to handler method parameters.