Comments on: Mocking collaborating Abstract class using EasyMock partial mocking

By: Naveen Kumar

Naveen Kumar — Mon, 18 Aug 2008 07:01:58 +0000

download
cglib-nodep-2.1_3.jar from
http://www.java2s.com/Code/Jar/Spring-Related/Downloadcglibnodep213jar.htm
add into classpath, it will work.
Hope this helps.

By: Nattu

Nattu — Thu, 31 Jul 2008 10:33:07 +0000

i am not able to run this testExpressAnger successfully. It gives me
java.lang.NoClassDefFoundError: net/sf/cglib/proxy/Enhancer

I used EasyMock2.3 and EasyMockClassExtension2.2.2

By: Xebia Blog

Xebia Blog — Mon, 25 Jun 2007 18:36:21 +0000

[...] If you’re not overriding any methods, the EasyMock partial mocking feature, which was presented in this blog entry, works as a charm. However if we’re extending a component, we probably want to override some of its methods and have it present a somewhat different behaviour. Let’s take a look at a small sample: public class CustomTree extends org.apache.myfaces.custom.tree2.HtmlTree { private String nodeId; [...]

By: Deepak Mittal

Deepak Mittal — Thu, 21 Jun 2007 03:22:48 +0000

Hi Lars,

Very valid & useful comments. Didn’t have these potential issues in mind, when I wrote this blog. I agree that it might be better to have some duplicate tests than to mock the methods in this manner.

But I assume there would be scenarios when we would be extending an abstract class in a third-party library in our application, though I could not recall an example quickly. In such cases, “partial mocking” seems to be a good option.

By: Lars Vonk

Lars Vonk — Mon, 18 Jun 2007 11:52:51 +0000

Hi Deepak,

Interesting technology but I think you should be cautious in using this technique for the following reasons:

- Refactoring support – Lets say you want to rename the speak method. Because the test refers to the speak method with the method name as String if does not get refactored (not in Eclipse that is). The same goes for adding parameters.

- Using this technique you wind up in focusing on what the method does instead of what it should do. I think (unit) tests should focus on what code should do.

I would prefer to exhaustively test the superclass speak() method separately and briefly test the expressAnger() method (which will test the speak() method again) in the concrete subclass. This might cause some duplication, but I rather have that then all these mocks.

By: Peter Veentjer

Peter Veentjer — Mon, 18 Jun 2007 08:34:31 +0000

Thanks Deepak for the useful information.

I normally extract the logic so I can test it, but this result in a lot of clutter (although with closures the clutter can be reduced because you need less interfaces).

But good to know how it works.. It will prevent long test methods (where all methods are tested and not just one in isolation).