Next, imagine that the Facade class and the Delegate interface below are part of a bigger system:

Create a matching easymock-test-config.xml (or mockito-test-config.xml).

Now, we have all the bits and pieces that are needed to start writing the integration test. We start simple to make sure that we autowiring and Spring context has been configured correctly:

The test is executed and it passes without any problem.

A second test is added to the same file with some added mock behavior:

Excellent, that test also passes.

Now that we have warmed up, we add a third test to the test class:

As expected, this test also passes without any problem.

Unfortunately, that is not always true. A closer investigation reveals that all tests pass when they are executed individually. When executing all three tests (either from the IDE or from a build tool like Maven), the third test fails unexpectedly:

java.lang.AssertionError:
  Unexpected method call Delegate.doSomethingElse():
        at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:44)
	at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:85)
	at $Proxy8.doSomethingElse(Unknown Source)
        [...]

This is EasyMock telling us that the mock object is in the wrong state. An EasyMock mock object goes through a series of steps:

1. Initialization - Instantiate the mock object.
2. Record - Record the expectations of the mock object.
3. Replay - Call replay() on the mock object so that it can replay the recorded state.
4. Test - Execute the test assertions.
5. Verify - Call verify() on the mock object to certify that the recorded mock expectations are fulfilled.

In an ordinary unit test, the mock object is thrown away after the verify phase, a new mock instance is created before the next test that can be used to record the new behavior. However, since we are creating a Spring integration test, there is one more thing to consider.

Reused beans

In the testing chapter of the Spring manual it is stated that:

By default, once loaded, the configured ApplicationContext and all of its beans are reused for each test method. Thus the setup cost is incurred only once (per test fixture), and subsequent test execution is much faster.

Consequently, all Spring beans, including mocked beans, will preserve their state between different test methods. The mock object will be in the verify state when the last test begins and not in the record state when delegateMock.doSomethingElse() is called. To solve the problem, we need some mechanism to ensure that the mock object is in a known, well-defined state before each test.

Reset mocks

Both EasyMock and Mockito provide methods to reset() the state of the mocked objects. Normally, resetting mock objects in the middle of a test method is considered to be a potential code smell, because it is likely that you are testing too much and that the test could be refactored into two separate tests accordingly. Nonetheless, resetting the mock instance @Before each test allow us to keep the same mock instance through the entire lifetime of the test class and yet put it in the record state when before each test starts:

When executing all tests in the test class, we see that that the problem has been solved and all tests pass.
For reference, click the link for the full source code of the EasyMock test class (and the Mockito test class).

Comments

You may choose to reset the mocks @After each test, the result will be the same.

The reset() method is called between the different test methods (because of the nature of @After and @Before), so the code smell of calling reset within a test is avoided.

Tests written using Mockito mocks are generally more tolerant for this kind of problem. In contrast to EasyMock, Mockito has no replay() method and no notion of steps. Therefore, it is possible to add additional mock expectations and to replace existing expectations, both after the test has been executed as well as after the result has been verified. Hence, you should always reset your mock objects before each test so that you do not get any accidental mocking behavior.

As a side note, another solution would be to annotate the test class (or all of its test methods) with the @DirtiesContext annotation. This will effectively recreate the entire application context after each test has been executed, causing all Spring beans to be in their initial state and thus the mock beans to be in the record state. Although this will work, there will be a significant performance penalty compared to the suggested reset() and @Before / @After solution, because all beans in the application context will be recreated and re-wired before each test method.

Dependencies

• Spring 3.0.6
• Mockito 1.8.5
• jUnit 4.10
• EasyMock 3.1

References

• Spring Reference Manual - Test Context Management and Caching
• Spring Reference Manual - SpringJunit4ClassRunner
• Spring Reference Manual - ContextConfiguration
• EasyMock
• Mockito

Previous post: Spring Integration Tests, Part I, Creating Mock Objects

(In this post, Mockito has been used for creating mock objects, but the same problem applies to EasyMock as well. You can find the corresponding files if you follow the provided links.)

Test setup

In the following example the SomeClass needs a reference to an instance of the SomeDependency interface:

When writing the integration test, we use the static Mockito.mock(Class classToMock) method to create a mock instance. The straightforward approach would be to let Spring instantiate the mock object with a static factory method in the xml configuration, e.g.

(Corresponding EasyMock config.)

To verify that the beans are created and wired correctly, we write a simple test:

(Same test for EasyMock, just update the @ContextConfiguration with the EasyMock config file.)

To our surprise, the test fails:

[...]
java.lang.IllegalStateException: Failed to load ApplicationContext
Caused by: org.springframework.beans.factory.BeanCreationException:
    Error creating bean with name 'someClass': Injection of autowired dependencies failed;
nested exception is org.springframework.beans.factory.BeanCreationException:
    Could not autowire field: private com.jayway.example.SomeDependency com.jayway.example.SomeClass.someDependency;
nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException:
    No matching bean of type [com.jayway.example.SomeDependency] found for dependency:
    expected at least 1 bean which qualifies as autowire candidate for this dependency.
    Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}
[...]

Explanation

In order to find a solution to the problem, we need to understand Spring's initialization process:

1. Load bean definitions.
   This step includes scanning the application context XML files, scanning packages defined by component-scan, and loading the bean definitions found into the bean factory. (BeanFactoryPostProcessors such as the PropertyPlaceHolderConfigurer may be called to update the bean definitions.)
2. Instantiate beans and store them in the application context.
   The bean factory creates the bean from the bean definitions. Bean dependencies get injected.
3. Bean post processing.
   All initializing methods (e.g. annotated with @PostConstruct, init-methods declared in the XML and the afterPropertiesSet() method will execute. Annotations such as @Required will be validated. Dynamic proxies in an AOP environment will be created and so on.

The problem that we see occurs due to a corner case in the first two steps. When the bean definition is created Spring scans through the application context XML file. It finds the declaration of the mock bean and a reflective call is made to find out the return type of the method defined by the factory-method declaration in an attempt to determine the bean's type. The return type of this method is declared as the formal type parameter <T> (remember that we use the Mockito.mock(Class<T> classToMock) as factory method). Consequently, the bean definition of someDependencyMock will be of java.lang.Object and not SomeDependency as one would think.

In the second step, the someClass bean is instantiated. Springs discovers the @Autowired annotation and tries to fetch an existing SomeDependency bean from the application context. None has yet been created, so the bean factory proceeds and looks for suitable bean definition in order to create an instance of the requested bean on the fly. This operation fails because the bean definition of someDependency is mapped to java.lang.Object. At this point, Spring bails out and throws the NoSuchBeanDefinitionException.

FactoryBean to the rescue

The problem is solved by implementing a custom FactoryBean that can be used whenever we need to mock an object:

(In the EasyMockFactoryBean, I have added an enum to define the type of mock object.)

Next, the Spring test config is updated to use the factory bean:

(Corresponding EasyMock config.)

Spring will still instantiate the beans in the order that they were declared in the mockito-test-config.xml, i.e. starting by creating an instance of SomeClass and then attempt to inject an instance of a SomeDependency into it before any has been created. The good news is that bean factory will scan through all declared FactoryBeans, calls its getObjectType() method, and if the returned type is correct, call its getObject() which should return an instance of the requested type.

Alternative solution

There is another more brittle solution to the problem. By simply changing the order of the tags in the initial application context, e.g. putting the bean declaration that defines the mock above the component scan, will cause the test to pass. The bean definition will still be wrong in the sense that the someDependencyMock will be defined as a java.lang.Object, but there is another important difference. In this case, the bean factory will invoke the Mockito.mock(Class<T> classToMock) method with SomeDependency as parameter causing the someDependencyMock bean to be created and subsequently stored in the application context. Later, the someClass bean is created and the dependency can obtained from the application context when requested by the bean factory and the wiring of the beans will succeed. However, making sure that the order of the bean declarations in the XML is always correct may neither be simple nor obvious, and it will get increasingly more difficult the more beans you add to the configuration.

Disclaimer

As stated in the in the first paragraph, I would only consider this solution for integration tests because of performance reasons. The application context itself adds some overhead, but the big performance hit is to create and wire all beans that are associated with it. When writing unit tests there is no need for this, so you could revert to constructor or setter dependency injection, Spring's ReflectionTestUtils.setField(), PowerMock's Whitebox.setInternalState(), Mockito's @InjectMocks or similar techniques.

Acknowledgements

Thanks to Wilhelm Kleu at stack overflow for suggesting the solution and to Mattias Hellborg Arthursson for valuable discussions.

Dependencies

• Spring 3.0.6
• Mockito 1.8.5
• jUnit 4.10
• EasyMock 3.1

References

• Spring Reference Manual - Static Factory Method
• Spring Reference Manual - FactoryBean
• Spring Reference Manual - Integration Testing
• Mockito
• EasyMock

Next post: Spring Integration Tests, Part II, Using Mock Objects

Dependency injection and early validation is crucial for an enterprise application, and Spring is a boon in this regard. But do not fool yourself, Spring is good, but it is not a universal cure. Especially not in mobile space where startup times, low memory consumption, and avoiding interfaces are virtues.

The bottleneck in an enterprise application is most probably the database, spending a few extra milliseconds here and there seldom matters. On much less performant mobile device those clock cycles are not only time the user has to spend waiting, it will drain the battery. A simple thing as using an interface instead of an abstract superclass will perform at least twice as slow. Even passing an extra argument in the constructors a few nestings deep will have an impact.

Lazy Singeltons by Choice

Class loading in Java is lazy, the Java VM will not load classes until they are referenced. Odds are that the user will not trigger a full coverage of all classes in your app for a short time running mobile app. If the user just checks for incoming messages and quits, then every class involved in composing messages do not need to be loaded. Early dependency injection breaks this, as all classes will be referenced at startup. Most components will be initialized in vain, as they are never actually used.

So what we should do in mobile application is to work more like the Java VM, and less like Spring. If possible do not create a component until it is requested. The best way to do this is using a singleton pattern. Not a normal enforced singleton pattern, but rather a singleton by choice. Let the constructor be public, trust your users, and name the getter getSharedFoo(), not getInstance(). Let me show you using a example of an URL cache component:

public class URLCache {
  private static URLCache sharedCache;

  public static URLCache getSharedURLCache() {
    synchronized (URLCache.class) {
      if (sharedCache == null) {
        sharedCache = new URLCache();
      }
    }
    return sharedCache;
  }

  public URLCache() {
    // More code...
  }
  // Allot more code here...

}

Using this shared URL cache component from our imaginary HTTP provider would then be super easy, but not mandatory:

public class HTTPProvider {

  public InputStream inputStreamForURL(String url) {
    URLCache cache = URLCache.getSharedURLCache();
    // Use the cache...
  }

}

The big win here is that if the code path of this run of the application never tries to open an input stream then the URL cache never has to be created. Saving several hundred milliseconds of reading cache indexes, validation, etc.

But What About Testing?

Are not singletons bad for unit tests and mocking components? They used to be. These days we have PowerMock, you really should use it. Turns out that not even PowerMock is really required, if we just change our singleton pattern very slightly, and allows the outside to set the shared component as well:

public class URLCache {
  private static URLCache sharedCache;

  public static void setSharedURLCache(URLCache cache) {
    synchronized (URLCache.class) {
      sharedCache = cache;
    }
  }

  public static URLCache getSharedURLCache() {
    synchronized (URLCache.class) {
      if (sharedCache == null) {
        sharedCache = new URLCache();
      }
    }
    return sharedCache;
  }

  // Allot more code here...

}

This small addition allows us for setup up our own mock cache in the setup of our unit tests. With something as simple as this:

public class SomeTest extends TestCase {

  public void setUp() {
    URLCache.setSharedURLCache(new NoOpURLCache());
  }

  public void testRemoteResource() {
    assertNotNull(HTTPProvider.getSharedHTTPProvider().inputStreamForURL(TEST_URL));
  }
}

It also allows us for explicitly override a singleton if our application has special needs, perhaps a more aggressive cache on a low bandwidth mobile data connection, or special implementation on a buggy Java ME platform. But most importantly for the normal case it will not waste time creating the component until it is actually needed, vastly improving the user experience for your mobile users.

Take Aways

Do not fear singletons, it is a great way of lazy creations that will greatly improve startup times and memory consumption on mobile applications.

Avoid using interfaces, they are at least twice as slow as classes, and can not have static methods for acquiring the lazy created components.

Do not enforce the singleton pattern, always use singleton by choice. To allow for testing and easy implementation of special cases.

Unit testing is a very powerful tool that should be included in every developer's toolbox. Unfortunately, this has not always been the case, especially not among MIDlet developers. One reason is that JavaME projects usually are small (compared to Java SE projects), which implies that manual testing could be enough. However, as soon as you start developing production code you really should consider to automate your tests by developing your own test suite.

Some of you may have played around with JMUnit project. It is a nice framework that allows you to write tests that can be transferred to your phone or emulator and you will see the test result on the display. Alternatively, the tests can be executed by Ant. Still, there are some limitations that you cannot bypass:

• Because of CLDC's lack of reflection, you cannot benefit from the powers of jUnit 4.x.
• You cannot create mock objects. This means that if a class has dependencies to other classes you will perform an integration test rather than a unit test.
• The turn around time for test, debug and retest, is significantly larger compared to Java SE unit testing, especially if you are executing the test on the phone.

No offence to the JMUnit guys, they are restricted by the limitations of the CLDC VM and the fact that you need a target device (a phone or an emulator) to run the tests on. But maybe there is a workaround to solve these problems? With some tricks, it is possible to unit test your JavaME code in the same way as you would unit test your Java SE code. In other words, you can execute the tests on the PC side without deploying the tests to an emulator or a phone.

PowerMock

One part of the solution is to mock any platform dependencies. Previously, it was an awkward job to do, but the introduction of PowerMock allows us to mock the many static methods in MIDP and CLDC. The easiest way to get started with powermock is to download the powermock-1.2-with-dependencies.zip. In another post I have explained how PowerMock can be used to mock the RecordStore in MIDP.

Project configuration

If you are using Eclipse, you need two projects, one for your phone application and the other your test code. This is because different projects can have different java compiler settings.

• Create a MIDlet project. This is your phone application. Make sure that the "Java Compiler" compliance level is "1.3".
• Create a Java project. This is the test project where you will write your tests. Make sure that the "Java Compiler" compliance level is set to "1.6" (or to whatever JDK version you have installed).
  • Add the midlet project you just created to "Required projects" in the "Java Build Path" setting.
  • Add the PowerMock jar files and their dependencies to "Libraries" in the "Java Build Path" setting.

In the MIDlet project, you write your application code and in the java test project you write your java jUnit tests. Normal package protection rules apply, so you should consider to reuse the package name from the class in the midlet project you would like to test when you are writing the test class in the java project.

Automation

Naturally, it is possible to automate the test by using build tools. Here is an example using of an Ant build.xml file:

 
<?xml version="1.0" encoding="UTF-8"?>
<project name="Example" default="test" basedir=".">
<property name="midlet.project.home" value="C:/your_workspace/MidletProject" />
<property name="test.project.home" value="C:/your_workspace/MidletProjectTest" />
<property name="powermock.home" value="C:/your_path/powermock-1.2" />
<property name="wtk.home" value="C:/WTK2.5.2" />
<property name="src.dir" value="${midlet.project.home}/src" />
<property name="test.src.dir" value="${test.project.home}/src" />
<property name="bin.dir" value="classes" />
<property name="test.bin.dir" value="test-classes" />
<property name="test.result.dir" value="test-result" />
<path id="midlet.dependencies">
		<fileset dir="${wtk.home}/lib">
			<include name="*.jar" />
		</fileset>
	</path>
<path id="test.dependencies">
<pathelement location="${bin.dir}" />
<path refid="midlet.dependencies" />
		<fileset dir="${powermock.home}" />
	</path>
 
	<target name="clean">
		<delete dir="${bin.dir}" />
		<delete dir="${test.bin.dir}" />
		<delete dir="${test.result.dir}" />
	</target>
 
	<target name="compile">
		<mkdir dir="${bin.dir}" />
		<javac srcdir="${src.dir}"
			destdir="${bin.dir}"
			source="1.3"
			target="1.1"
			classpathref="midlet.dependencies" />
	</target>
 
	<target name="compile-tests" depends="compile">
		<mkdir dir="${test.bin.dir}" />
		<javac srcdir="${test.src.dir}"
			destdir="${test.bin.dir}"
			classpathref="test.dependencies" />
	</target>
 
	<target name="test" depends="clean, compile-tests">
		<mkdir dir="${test.result.dir}" />
		<junit printsummary="yes">
			<classpath refid="test.dependencies" />
			<classpath path="${test.bin.dir}" />
<formatter type="plain" />
			<batchtest fork="yes" todir="${test.result.dir}">
				<fileset dir="${test.src.dir}" />
			</batchtest>
		</junit>
	</target>
</project>
 

Now your project configuration is setup and you can test your MIDlet code in the same way as you would test your Java SE code.

What's next?

If you are a dedicated MIDlet developer you would probably like to add more build targets later on to preverify, obfuscate, sign, package and deploy your MIDlet.

You should also consider using a continuous integration server together with your version control system and configure it to run your test suite whenever the code has been changed. Depending on the server you choose, you may also find that it may be used to present result from static code analysis tools, code coverage, code metrics and so on.

PowerMock is a mocking framework that claims to have almost supernatural powers. According to its documentation it is able to mock both static and private methods, final classes, and other nasty things that would be insurmountable obstacles for other mock frameworks. As a result, it has been stated that it should be able to mock the MIDP RecordStore, but so far I have not seen a working example. I accepted the challenge.

Getting started

I decided that writing a unit test was the best way to get started. After all, mocking is usually used together with unit testing.
In order to use RecordStore you must first open it. According to the javadoc of RecordStore, the method to be used is: public static RecordStore openRecordStore(String recordStoreName, boolean createIfNecessary).
A static method that returns an instance of the RecordStore object. Following the "Mocking static methods" guidelines on the PowerMock web site, it seemed to be a pretty straight forward task:

1. Use the @RunWith annotation at the class-level of the test case.
2. Use the @PrepareForTest annotation at the class-level of the test case.
3. Use PowerMock.mockStatic() to mock all methods of this class.
4. Use PowerMock.replay() to change the class to replay mode.
5. Use PowerMock.verify() to change the class to verify mode.

Ok, a little more complicated than my ordinary EasyMock setup, but nothing to really worry about. In my case, I also needed to create a mock object of the RecordStore class itself because of the return value of the openRecordStore() method.

The setback

To my disappointment, my test failed with an ExceptionInInitializerError. I studied the code thoroughly to make sure that I had followed the instructions, but I concluded that error resided elsewhere. A closer look at the failure trace revealed:

[...]
Caused by: java.lang.UnsupportedOperationException: getSlowingFactor is native
at javax.microedition.rms.RecordStore.getSlowingFactor(RecordStore.java)
at javax.microedition.rms.RecordStore.(RecordStore.java:2414)
[...]

Hmm, that is strange... According to the API, there should be no getSlowingFactor() in RecordStore? And it seems like it is called by the class initializer? When searching for an answer it seemed like this problem occurs if you have not configured the preverifier correctly. It sort of makes sense, I am not using a preverifier at all in my project and I did not like the idea of introducing one.

The solution

Returning to the PowerMock documentation, I discovered instructions how to "Suppressing Unwanted Behavior", maybe this was the way forward? Soon, I found the annotation @SuppressStaticInitializationFor, I added it to my test case and voilà, I had successfully mocked the RecordStore!

Reference code

You can find the code needed to mock the RecordStore below. If you find it interesting, you can download a more complex example where a class that uses RecordStore for persistent storage is unit tested with aid of PowerMock.

 
import static org.easymock.EasyMock.expect;
import static org.easymock.classextension.EasyMock.createMock;
import static org.junit.Assert.assertEquals;
import javax.microedition.rms.RecordStore;
import javax.microedition.rms.RecordStoreException;
 
import org.junit.Test;
import org.junit.runner.RunWith;
import org.powermock.api.easymock.PowerMock;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.core.classloader.annotations.SuppressStaticInitializationFor;
import org.powermock.modules.junit4.PowerMockRunner;
 
@RunWith(PowerMockRunner.class)
@PrepareForTest(RecordStore.class)
@SuppressStaticInitializationFor("javax.microedition.rms.RecordStore")
public class RecordStoreMockTest {
 
	@Test
	public void testCreateRecordStoreMock() throws RecordStoreException {
		String recordStoreName = "record_store_name";
 
		// Create mocks
		PowerMock.mockStatic(RecordStore.class);
		RecordStore recordStoreMock = createMock(RecordStore.class);
 
		// Record behavior
		expect(RecordStore.openRecordStore(recordStoreName, true)).andReturn(
				recordStoreMock);
 
		// Replay behavior
		PowerMock.replay(RecordStore.class);
 
		// Execute test and verify result
		assertEquals(recordStoreMock, RecordStore.openRecordStore(recordStoreName, true));
		PowerMock.verify(RecordStore.class);
	}
}
 

One interesting problem was that in some of my tests, I had to mock the org.eclipse.core.resources.IResource interface. Nothing too hard about that, just write the following code, using EasyMock 2.4:

 
@Override
protected void setUp() throws Exception {
   super.setUp();
   resource1 = createMock("resource1", IResource.class);
   resource2 = createMock("resource2", IResource.class);
}
 

Now to my problem. First, I will discuss what the IResource.accept(IResourceVisitor visitor) metod does:
The IResource.accept(...) method traverses the directory structure under the resource. For each resource found, starting with the IResource on which accept() was called, the visitor.visit(IResource resource) method is called. If the visit(...) method returns true, the directory structure under the resource is traversed, otherwise traversing stops for that specific resource. This way parts of the directory structure under an IResource can be visited.

The problem I encountered was that since I have an IResource mock, there is no code for the accept() method. The mock will just register that there has been a call for accept(), but the code in the IResourceVisitor.visit(IResource resource), which I want tested, is never called.

What to do? There are different solutions, one example is to use an implementation of IResource, for example org.eclipse.core.internal.resources.Folder, and create a partially mocked object and keep the code for accept(). Not a nice solution though, my test would depend on internal code in the Eclipse project. What I did instead was to use the org.easymock.EasyMock.expectLastCall().andAnswer(IAnswer answer) functionality. The andAnswer() method takes an IAnswer callback implementation, like this:

 
public void testCollectRefreshStatus() throws CoreException {
   // Normal mock expects
   expect(resource1.getLocation()).andReturn(iPath1);
   expect(iPath1.toOSString()).andReturn(RESOURCE_PATH_1).times(2);
 
   // Provide code for accept(...)
   resource1.accept(isA(IResourceVisitor.class));
   expectLastCall().andAnswer(new IAnswer() {
      public Object answer() throws Throwable { // 1.
        IResourceVisitor visitor = (IResourceVisitor) EasyMock.getCurrentArguments()[0]; // 2.
        visitor.visit(resource2); // 3.
        return null;
      }
   });
   expect(resource2.getName()).andReturn("file.txt"); // 4.
 
   replayMocks();
 
   // Perform test
   myTestTarget.someMethod();
 
   // Verify test
   assertEquals(1, myTestTarget.getNumberOfResources());
   verifyMocks();
}
 

Here are some comments to the marked lines in the code above:

1. The answer() method is dictated by the IAnswer interface.
2. EasyMock provides a method to get access to the objects sent as parameters for the expected call. In this case, the call is resource1.accept(...) and the parameter is the IResourceVisitor implementation defined in myTestTarget, which is the code that should be tested.
3. Here the test code has control of the call to the IResourceVisitor.visit() and a mock IResource is provided as parameter. To make the test even better, the boolean return value from the visit() call should be saved and asserted for the correct value to ensure that the intended traversing works as expected.
4. Here the expectations on the mock IResource, for the visit(IResource ...) call, is defined. In this case myTestTarget calls getName() on IResource for some reason, so expectations for that is defined together with a resulting return value that would steer the logic in some direction.

This way the test has full control of the visitor implementation and it is fairly easy to test all the criterias that makes the IResourceVisitor.visit(...) implementation return true or false. Also, the visit() method often changes state of something else, and here it is also possible to test that the state is changed correctly by simulating multiple visit(...) calls, by adding more calls to visit at 3. in the code above.

/Tobias Södergren

We now think that the API is stable enough and we have also tested PowerMock in a couple of projects, but of course since we were presenting at the conference it is no coincidence that we released PowerMock 1.0 just days before.

The details of the changes can be found in the changelog but here are some of the highlights since PowerMock 0.8:

• The ability to set and get internal state based on an object type. This means that you get more refactor friendly code while still being able to set internal state.
• Implemented replayAll and verifyAll. These can be used to replay and verify all mocks created by PowerMock without having to explicitly specify each and everyone. Thanks to Ivar Grimstad for suggesting this!
• Added support for specifying parameter types for expectNew. Mocking constructor calls is a unique feature of PowerMock that people typically find very cool!

During the conference I talked to several people and got really good feedback. Everybody seemed to like the idea of being able to unit test legacy code and code that haven't been designed for testing. Kevlin Henney made a good job of defining and describing various types of unit testing during his talk at Øredev and we talked about the difference between essentially untestable code and accidentally untestable code. PowerMock solves the problem with code being untestable for technical reasons (part of the accidentally untestable). With all the great sessions and good discussions Øredev was yet again a great experience!

I have made the slides from the presentation available at powermock.org. Note that the demo we showed was actually from the trunk and not from the 1.0 release!

We have received some feedback and have also started some evaluation in one of our customer's project. Besides bug-fixes and documentation updates we are starting to stabilize the API and preparing for the 1.0 release. We are also presenting PowerMock at this years Øredev conference. You're more than welcome to try it out for yourself.

Unexpected method call toString():
  toString(): expected: 0, actual: 1

You think nothing of it and happily add an expectation for toString. Then you get:

Unexpected method call toString():
  toString(): expected: 1, actual: 2

The reason is that EasyMock itself calls toString for each expectation, so it's a never-ending story. However, it appears only when your class under test has overridden any (or all) of toString, equals or hashCode. There is a way around it. You can tell EasyMock's MockClassControl which methods you want it to mock. Yes, you heard it right: "which methods you want it to mock". I know, you'd rather want to tell it which methods you don't want it to mock, like toString, equals and hashCode.

I'll show you a couple of utility classes that let you do that. We ran into this problem in a previous project and wrote the classes below. They let you get away with this neat code that should be used whenever you mock a class:

public class MyClassTest extends TestCase {
   private MockControl myClassControl;
   private MyClass myClassMock;
 
   public void setUp(){
      myClassControl = TestUtils.createClassControl(MyClass.class);
      myClassMock = (MyClass) myClassControl.getMock();
   }
   ...
}

Here are the classes:

package se.jayway.testutils; 
 
import org.easymock.MockControl; 
 
/**
 * Various utility functions for testing.
 *
 * @author Adam Skogman
 */
public final class TestUtils { 
 
    private TestUtils() {
        super();
    } 
 
    /**
     * Get a MockClassControl for the supplied class, using the first found
     * public or protected constructor and not mocking the toString(), equals()
     * and hashCode() methods.
     *
     * @param cls
     *            the class to create a MockClassControl for.
     * @return a MockClassControl for the class.
     * @see MockClassControlHelper
     */
    public static MockControl getMockClassControl(Class cls) {
        return getMockClassControl(
                cls,
                MockClassControlHelper.DONT_MOCK_STD_METHODS);
    } 
 
    /**
     * Get a MockClassControl for the supplied class, using the first found
     * public or protected constructor. If mockStdMethods is false, the
     * toString(), equals() and hashCode() methods will not be mocked.
     *
     * @param cls
     *            the class to create a MockClassControl for.
     * @param mockStdMethods
     *            whether toString(), equals() and hashCode() will be mocked.
     * @return a MockClassControl for the class.
     * @see MockClassControlHelper
     */
    public static MockControl getMockClassControl(
            Class cls,
            boolean mockStdMethods) {
        MockClassControlHelper helper = new MockClassControlHelper(
                mockStdMethods);
        return helper.getMockClassControl(cls);
    }
}

package se.jayway.testutils; 
 
import java.lang.reflect.Constructor;
import java.lang.reflect.Method;
import java.lang.reflect.Modifier;
import java.util.Arrays;
import java.util.Collection;
import java.util.HashSet;
import java.util.Set; 
 
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.easymock.MockControl;
import org.easymock.classextension.MockClassControl; 
 
/**
 * Helper class to easily create mock class controls.
 *
 * EasyMockClassExtension v1.1 has a couple of undocumented 'features' which are
 * rather annoying.
 *
 * First of all, if the class we want to mock does not have any public
 * constructor, it is not possible to do
 * MockClassControl.createControl(MyClass.class), since the search for
 * constructors is limited to 'public' access modifier if class and parameter
 * values are not specified.
 *
 * Secondly, if toString(), equals() or hashCode() is overridden in the class we
 * want to mock, parameter matching on the resulting mock will not work, since
 * the above methods will be mocked by default, causing mock control validation
 * to fail.
 *
 * As a solution this helper class will by default instruct MockClassControl not
 * to mock toString(), equals() and hashCode() (alternatively any methods
 * specified by a call to setStdMethods()).
 *
 * Methods in Object will not be mocked.
 *
 * @author Mattias Arthursson
 */
public class MockClassControlHelper {
    Log log = LogFactory.getLog(MockClassControlHelper.class); 
 
    /**
     * Indicates that standard methods will be mocked.
     */
    public static final boolean MOCK_STD_METHODS = true; 
 
    /**
     * Indicates that standard methods will be mocked.
     */
    public static final boolean DONT_MOCK_STD_METHODS = false; 
 
    private boolean mockStdMethods; 
 
    private Collection stdMethods; 
 
    /**
     * Initialize to not mock standard methods.
     */
    public MockClassControlHelper() {
        this(DONT_MOCK_STD_METHODS);
    } 
 
    /**
     * Initialize to mock standard methods depending on supplied parameter.
     *
     * @param mockStdMethods
     *            whether standard methods should be mocked.
     */
    public MockClassControlHelper(boolean mockStdMethods) {
        this.mockStdMethods = mockStdMethods;
        stdMethods = Arrays.asList(new String[] { "toString", "equals",
                "hashCode" });
    } 
 
    /**
     * Get a MockClassControl for the supplied class using the first found
     * public or protected constructor. Standard methods will be mocked
     * depending on mockStdMethods.
     *
     * @param cls
     *            the class to mock.
     * @return a MockClassControl for the supplied class.
     */
    public MockControl getMockClassControl(Class cls) {
        Constructor constructorToUse = getConstructorToUse(cls); 
 
        Class[] parameters = constructorToUse.getParameterTypes();
        Object[] values = new Object[parameters.length]; 
 
        Method[] methodsToMock = getMethodsToMock(cls); 
 
        return MockClassControl.createControl(
                cls,
                parameters,
                values,
                methodsToMock);
    } 
 
    /**
     * Set the standard methods to omit if mockStdMethods is set to false
     * (default).
     *
     * @param methods
     *            Names of the methods to omit when mocking.
     */
    public void setStdMethods(String[] methods) {
        stdMethods = Arrays.asList(methods);
    } 
 
    /**
     * Set the standard methods to omit if mockStdMethods is set to false
     * (default).
     *
     * @param c
     *            Collection of names of the methods to omit when mocking.
     */
    public void setStdMethods(Collection c) {
        stdMethods = c;
    } 
 
    /**
     * Get the methods that will not be mocked.
     *
     * @return A collection of method names.
     */
    public Collection getStdMethods() {
        return stdMethods;
    } 
 
    /**
     * Find a constructor to use. If public constructors are found, the first of
     * these is selected. Otherwise we check for a protected constructor, and
     * the first of these is used.
     *
     * @param cls
     *            Class to select a constructor from.
     * @return a public or protected constructor for the class.
     */
    protected Constructor getConstructorToUse(Class cls) {
        Constructor[] constructors = cls.getConstructors();
        if (constructors.length == 0) {
            // No public constructors found.
            constructors = cls.getDeclaredConstructors();
            if (constructors.length == 0) {
                throw new IllegalArgumentException("Class '" + cls
                        + "' does not have any constructors");
            }
        } 
 
        for (int i = 0; i < constructors.length; i++) {
            int modifiers = constructors[i].getModifiers();
            if (Modifier.isPublic(modifiers) || Modifier.isProtected(modifiers)) { 
 
                // We've found a constructor which is public or
                // protected - use that one.
                return constructors[i];
            }
        } 
 
        // No public or protected constructor found.
        throw new IllegalArgumentException("Class '" + cls
                + "' does not have any public or protected constructors");
    } 
 
    /**
     * Figure out which methods of the class to mock. If mockStdMethods is set
     * to false, the standard methods are subtracted from all found methods for
     * the class. Otherwise all methods for the class is returned.
     *
     * @param cls
     *            The class to get methods for.
     * @return The methods to mock for the class.
     */
    protected Method[] getMethodsToMock(Class cls) { 
 
        Class currentClass = cls;
        Set methods = new HashSet(); 
 
        while (currentClass != null) {
            Method[] methodArray = currentClass.getDeclaredMethods(); 
 
            for (int i = 0; i < methodArray.length; i++) {
                Method method = methodArray[i];
                boolean isStandardMethod = stdMethods.contains(method
                        .getName());
                if (mockStdMethods || !isStandardMethod) {
                    methods.add(method);
                } 
 
                if ((method.getModifiers() & Modifier.FINAL) > 0) {
                    log.warn("Final method, cannot be mocked: " + method);
                }
            } 
 
            currentClass = currentClass.getSuperclass();
            if(currentClass == Object.class){
                currentClass = null;
            }
        } 
 
        return (Method[]) methods.toArray(new Method[methods.size()]);
    }
}

 
public class StupidSingleton {
	public static String doStatic(int i) {
		throw new UnsupportedOperationException("method not implemented yet...");
	}
 
	public static void sayHello() {
		System.out.println("Hello");
	}
 
	public static native void nativeMethod();
}
 

We would like to write something like this:

 
	public void testMocking() {
		mock(StupidSingleton.class);
		expect(StupidSingleton.doStatic(17)).andReturn("17");
		StupidSingleton.sayHello();
		StupidSingleton.nativeMethod();
		replay(StupidSingleton.class);
 
		assertEquals("17", StupidSingleton.doStatic(17));
		StupidSingleton.sayHello();
		StupidSingleton.nativeMethod();
 
		verify(StupidSingleton.class);
	}
 

After playing around with AspectJ I discovered that this is actually possible! Two things are needed:
* An aspect that allows us to catch calls to static methods!
* An implementation of the mock, replay, verify for classes

This turns out to be really easy! The following aspect catches ALL calls to ALL static methods. Might be a bit aggressive, but it works! If you want you can implement your own aspect with a more specialized pointcut.

 
@Aspect
public class StaticMockAll extends StaticMockAspect {
	@Pointcut("call(static * *(..))")
	public void anyStaticOperation() {}
 
	@Around("anyStaticOperation()")
	public Object aroundStaticMethods(ProceedingJoinPoint jp) throws Throwable {
		return super.aroundStaticMethods(jp);
	}
 
}
 

The mock, replay, verify methods turns out to be trivial:

 
public class StaticMock {
	static Map<Class, MockInvocationHandler> mocks = new HashMap<Class, MockInvocationHandler>();
 
	public static synchronized void mock(Class type) {
		MockInvocationHandler h = new MockInvocationHandler((MocksControl) EasyMock.createControl());
		mocks.put(type, h);
	}
 
	public static synchronized void replay(Class type) {
		mocks.get(type).getControl().replay();
	}
 
	public static synchronized void verify(Class type) {
		mocks.remove(type).getControl().verify();
	}
}
 

Finally, the base class for the aspect that does the actual work is also quite simple:

 
public class StaticMockAspect {
	public Object aroundStaticMethods(ProceedingJoinPoint jp) throws Throwable {
		Class type = jp.getSignature().getDeclaringType();
		InvocationHandler h = getInvocationHandler(type);
		if (h == null) {
			return jp.proceed();
		}
		MethodSignature methodSignature = ((MethodSignature)jp.getSignature());
		return h.invoke(type, methodSignature.getMethod(), jp.getArgs());
	}
 
	private MockInvocationHandler getInvocationHandler(Class type) {
		synchronized (StaticMock.class) {
			return StaticMock.mocks.get(type);
		}
	}
 
}
 

h3. Notes

Things to note and think about:
* Static methods and native methods can be mocked! By using the "call" pointcut we change all code that tries to call the native methods and not the native method itself.
* AspectJ is required to make this work. I have been using Eclipse AJDT
* It should be possible to replace the Aspect with "plain" byte code manipulation and "just" reload the class.