When testing a static method that internally calls Base64.encodeToString() in an Android project, using PowerMockito’s mockStatic(Base64.class) with the @PrepareForTest annotation results in the error ClassNotPreparedException: The class android.util.Base64 not prepared for test. Even after adding the class to @PrepareForTest({Base64.class}), the issue persists. Why does this happen when mocking Android framework classes with PowerMockito, and what’s the correct way to handle this in unit tests?
I’ve run into this issue a few times myself! The org.powermock.api.mockito.ClassNotPreparedException happens because PowerMockito struggles with mocking static methods from Android framework classes, like android.util.Base64. These classes are final, and since they’re loaded by the system classloader, PowerMockito can’t properly instrument them for mocking. Even if you add Base64.class to @PrepareForTest, it still won’t work because the JVM doesn’t allow the class to be overridden by PowerMockito.
The best workaround I found is to create a wrapper class around the Android static method. This approach makes testing much easier and sidesteps issues with mocking the Android internals. Here’s a quick example:
public class Base64Wrapper {
public String encode(String input) {
return Base64.encodeToString(input.getBytes(), Base64.NO_WRAP);
}
}
Then in your unit test, mock Base64Wrapper.encode() using Mockito or PowerMockito. This method is much cleaner and safer, and it avoids the headache of dealing with Android’s static methods directly.
Exactly, @vindhya.rddy ! Android framework classes like Base64 and TextUtils can be a real pain to mock with PowerMockito. I tend to avoid mocking Android system classes altogether. Instead, I create a thin wrapper around those static calls. This not only makes your code more testable but also keeps it more maintainable, as you’re not directly tied to the Android framework. It’s a small change that pays off in the long run.
For example, using the Base64Wrapper approach keeps your code flexible and testable without the need to mess around with the internal Android classes. Plus, you get rid of that annoying org.powermock.api.mockito.classnotpreparedexception every time you try to mock something static!
I totally agree with both of you. Another thing I’ve learned over time is that if you really want to avoid the whole org.powermock.api.mockito.classnotpreparedexception headache, you can use Robolectric. Robolectric runs Android SDK classes in the JVM, so when you use Base64.encodeToString(), it just works like it does on a real device. It’s a great tool for unit testing Android methods without worrying about PowerMockito.
Combining Robolectric with a wrapper class like the one you mentioned is a solid approach. You get the benefits of the wrapper for testability and maintainability, and Robolectric handles the tricky Android internals for you. It’s a nice compromise if you’re trying to unit test code that involves Android static methods like Base64.