Filed under: asm

jMock and interfaces galore

The ASM pain is now over with, I think. I've tried various mocking packages and settled on jMock. There really isn't a huge difference between jMock and EasyMock. In fact, they both use CGLib. However, there are some subtle differences.

First, jMock integrates better with JUnit 4.4. This is pretty cool. If I were so inclined, I could specify exactly which mocked methods are called and the sequence in which they should be called. I can even specify several sequences. Then, at the end of each test, it would check the expectations and throw an exception. I also like the smaller overhead of jMock. EasyMock forces you to perform a lot more setup overhead for each mocked object. This can be pretty annoying. jMock simlpy makes me annotate the class, create a Mockery (I love the jMock terminology), create the mock, put it where it belongs, and create Expectations. There is no need to call a method to start the replay because I'm not calling the methods on the actual mocked object to set the expectations.

Second, jMock uses CGLib but provides a dependency-free version of the JAR. This allows me to more safely put it at the front of the classpath. I have used this a bit with hibernate being called and see no issues.

Finally, if you need to mock a class rather than an interface, you have to use an Imposteriser. That has to be the best word that I've ever typed into code. Therefore, jMock wins style points.

Of course, I have done a lot of work on this and just now realized that I'm only mocking a single class. That class is used in a package that doesn't need to call hibernate in the unit tests. That makes my life a lot easier. This is mostly due to the fact that one of the custom service dispatchers we use is a final class. That made it impossible to mock. I ended up creating a singleton that my unit tests could replace. Since I wrote it, I could make an interface for it. At this point, the only thing class I'm mocking is InitialLdapContext. I think this is a pretty good situation.

There you have it. ASM pain still exists in the world, but I've found my way around it.

ASM is not my friend

I am currently working on cleaning up our unit tests at work. Our service code calls several other services within the company. However, we don't necessarily want those called during the unit tests. Development-level services are notoriously unreliable. I have started using EasyMock 2.3 to mock the interfaces for our dependencies. However, some of the things we need to do require mocking classes. Enter EasyMock Class Extensions 2.3.

I first tried to use the class extensions and immediately got a NoSuchMethodError when running my tests. To make a long (and painful) story short, Hibernate imports a version of ASM that is newer than the one used by EasyMock Class Extensions. Luckily, the particular package I\'m using doesn't need Hibernate. It only gets included in the classpath because it is in the list of transitive dependencies. However, once I start using Hibernate, I fear it will not work. I will be trying this out today. If anyone has any ideas, though, please let me know.

web
stats