JUnit recipes: Work around static attributes in classes

Beware of the class loader. I recently had a major testing problem with some code because I didn’t take the (sometimes ugly) Java class loading mechanism into account. There was a small class where I wanted to unit test the calculateAge method.

So I dropped EasyMock into my project and mocked the person class. I was using jMock in the past and could live with methods as strings. With the new JMock 2 syntax this has changed. I still struggle with {{ in JMock expectations and so does my IDE. When IDEA learns to format JMock expectations, I’m back. For now I’m using EasyMock though, sometimes with JMock assertions from the excellent Hamcrest assertion library. Back to the problem at hand . The mock was passed into the AgeCalculator to calculate the age of the person. The problem was the Person class.

Even though I didn’t use the Person class, just a mock, the static attributes where initialized and the DatabaseConfiguration tried to load data from the backend. This happens whenever your classloader sees the Person type, even in an interface.

Using Calculator in mocks will initialize the static attributes in Person. Which contradicted the isolation principle of unit tests and also led to long startups of the database backend. This stopped my efforts to test the AgeCalculator. Time passed.

Then I stumbled upon JMockit. Others have too. The friendly and supportive developers of JMockit have helped (thanks Rogerio) and with a simple line I was saved:

Constructs like the above with static attributes should never be created in the first place (hello all those people who propagate static inialized attributes for singletons to avoid synchronized). But if you have such code in your legay base, JMockit to the rescue.

Thanks for listening.

Bought VMWare Fusion after Parallels

I’ve switched! After using Parallels for some time to run Windows applications I’ve tried the VMWare Beta. And I was astonished how polished the Beta already was. It felt much more stable and professional than Parallels. And when with Parallels I had troubles even after I upgraded to 2gb of memory and it captured 100% CPU from time to time, VMWare runs smooth and without problems. Sharing folders is also much easier, e.g. it’s easy to share your home directory. USB drive handling works better. So although I bought Parallels before and there was no cross update I jumped shipped and bought VMWare too. I’m very satisfied. As an additional bonus VMWare has lots of public images like Linux which we use at work or Solaris which I always wanted to try. Excellent product. I only wish they could think of a way to supsend boot camp partitions.

Grails more productive than Rails

Catchy title. But the guys from ALTERthought have some – much needed – numbers. Their numbers show Grails to be more productive than Rails, which is in turn more productive than Spring and pure JEE. As I’ve argued for years, there is no science in computer science. We need to put facts back into computer science. Hard numbers instead of faery tales. Hacknot thinks so too. Thanks for the real numbers. Two thoughts:

  1. This is development effort, not maintenance. Glass shows that 40 to 80 % of effort go into maintenance.
  2. We compared Grails to Seam and think they have much in common. Seam productivity should be nearer to Grails than to the standard JEE stack

Thanks for listening.