How to mock MIDP RecordStore

The challenge

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.

Mattias Severson

Mattias is a senior software engineer specialized in backend architecture and development with experience of cloud based applications and scalable solutions. He is a clean code proponent who appreciates Agile methodologies and pragmatic Test Driven Development. Mattias has experience from many different environments, including everything between big international projects that last for years and solo, single day jobs. He is open-minded and curious about new technologies. Mattias believes in continuous improvement on a personal level as well as in the projects that he is working on. Additionally, Mattias is a frequent speaker at user groups, companies and conferences.

This Post Has 3 Comments

  1. Hi Mattias,

    i dont know whats the need of this mock
    could you explain :)

    1. Agreeable, as a unit test the code above does not make much sense. The purpose of the example was to show that it is possible to perform unit tests of Midlet code using PowerMock.

      Did you look at the attached code example? It consists of two classes, “PersistentData.java” and “PersistentDataTest.java”. The first class persists data to the RecordStore and the second class contains the corresponding unit tests. Hopefully, you will find them more useful when developing your own tests.

      Additionally, my post Getting started with JavaME jUnit testing may also interest you.

  2. i’ll try to read the attachment.

    Thanks :)

Leave a Reply

Close Menu