Java Tutorials, Kotlin Tutorials, Mockito Tutorials, Testing Tutorials

Mocking Static Methods with Mockito (Java & Kotlin)

Last Updated: March 15, 2023 | Published: October 7, 2020

Want to start a religious discussion? Start asking your teammates whether or not you should mock static method calls. It's debatable if this is an absolute no-go or sometimes a last resort. I agree that you should rethink your implementation if you find yourself googling: Mocking static calls Java. On the other side, there are still valid use cases where this approach is considerable. In the past, PowerMock was the most popular solution for this problem in Java. Starting with version 3.4.0, Mockito now supports mocking static methods.

PS: Before arguing with your co-workers, read through the different opinions around mocking static methods at the corresponding GitHub issue from Mockito.

Required Mockito Maven Setup

Mocking static methods is part of Mockito since version 3.4.0.

If we are using Maven, we can either update our existing Mockito version or include the following dependency to your pom.xml:

<dependency>
  <groupId>org.mockito</groupId>
  <artifactId>mockito-inline</artifactId>
  <!-- version needs to be >= 3.4.0 -->
  <version>4.6.1</version> 
  <scope>test</scope>
</dependency>

<groupId>org.mockito</groupId>

<artifactId>mockito-inline</artifactId>

</dependency>

If our project uses mockito-core, we'll see the following exception and should replace it with mockito-inline.

org.mockito.exceptions.base.MockitoException: 
The used MockMaker SubclassByteBuddyMockMaker does not support the creation of static mocks

Mockito's inline mock maker supports static mocks based on the Instrumentation API.
You can simply enable this mock mode, by placing the 'mockito-inline' artifact where you are currently using 'mockito-core'.
Note that Mockito's inline mock maker is not supported on Android.

org.mockito.exceptions.base.MockitoException:

The used MockMaker SubclassByteBuddyMockMaker does not support the creation of static mocks

Mockito's inline mock maker supports static mocks based on the Instrumentation API.

You can simply enable this mock mode, by placing the 'mockito-inline' artifact where you are currently using 'mockito-core'.

Note that Mockito's inline mock maker is not supported on Android.

When developing an application with Spring Boot and the Spring Boot Starter Test, we can update to Spring Boot Version 2.4.0-M2. This version includes the Mocktio dependency in a compatible version (> 3.4.0).

If our project can't update the main Spring Boot version (yet), we can manually override the used Mockito version using:

<properties>
  <mockito.version>4.6.1</mockito.version>
</properties>

<mockito.version>4.6.1</mockito.version>

</properties>

And include mockito-inline if required:

<dependency>
  <groupId>org.mockito</groupId>
  <artifactId>mockito-inline</artifactId>
  <scope>test</scope>
</dependency>

<groupId>org.mockito</groupId>

<artifactId>mockito-inline</artifactId>

</dependency>

Update: Starting with Mockito version 5.0.0, the mockito-inline is now the default MockMaker. If we're using this version, we can skip any manual configuration to use the InlineMockMaker.

Important: The upcoming code examples use Java 11. Not everything will work with Java 8 as expected, as the internals of UUID.toString() did change between those two Java releases.

Mocking Static Methods With Java

Let's take a look at how to use this feature for a Java method that accesses two static methods: UUID.randomUUID() and LocalDateTime.now().

Whether or not this implementation or the corresponding tests make sense is not up for discussion. The example is only for demonstration purposes on how to mock static method calls with Mockito.

public class OrderService {
  
  public Order createOrder(String productName, Long amount, String parentOrderId) {
    Order order = new Order();
    
    order.setId(parentOrderId == null ? UUID.randomUUID().toString() : parentOrderId);
    order.setCreationDate(LocalDateTime.now());
    order.setAmount(amount);
    order.setProductName(productName);

    return order;
  }
}

public class OrderService {

public Order createOrder(String productName, Long amount, String parentOrderId) {

Order order = new Order();

order.setId(parentOrderId == null ? UUID.randomUUID().toString() : parentOrderId);

order.setCreationDate(LocalDateTime.now());

order.setAmount(amount);

order.setProductName(productName);

return order;

}

With the first test, we want to make sure to use a random UUID whenever we don't pass a parentOrderId:

class OrderServiceTest {

  private OrderService cut = new OrderService();
  private UUID defaultUuid = UUID.fromString("8d8b30e3-de52-4f1c-a71c-9905a8043dac");
  private LocalDateTime defaultLocalDateTime = LocalDateTime.of(2020, 1, 1, 12, 0);

  @Test
  void shouldIncludeRandomOrderIdWhenNoParentOrderExists() {
    try (MockedStatic<UUID> mockedUuid = Mockito.mockStatic(UUID.class)) {
      mockedUuid.when(UUID::randomUUID).thenReturn(defaultUuid);

      Order result = cut.createOrder("MacBook Pro", 2L, null);

      assertEquals("8d8b30e3-de52-4f1c-a71c-9905a8043dac", result.getId());
    }
  

    // ... next test

}

class OrderServiceTest {

private OrderService cut = new OrderService();

private UUID defaultUuid = UUID.fromString("8d8b30e3-de52-4f1c-a71c-9905a8043dac");

private LocalDateTime defaultLocalDateTime = LocalDateTime.of(2020, 1, 1, 12, 0);

@Test

void shouldIncludeRandomOrderIdWhenNoParentOrderExists() {

try (MockedStatic<UUID> mockedUuid = Mockito.mockStatic(UUID.class)) {

mockedUuid.when(UUID::randomUUID).thenReturn(defaultUuid);

Order result = cut.createOrder("MacBook Pro", 2L, null);

assertEquals("8d8b30e3-de52-4f1c-a71c-9905a8043dac", result.getId());

}

// ... next test

}

Here we are using a try-with-resources statement to create a mocked version of the UUID class. This is because MockedStatic extends the ScopedMock interface, which itself extends AutoClosable. The static mocks are thread-local scoped and hence need to be closed.

Inside the try-with-resources statement, we then get access to the mocked version of UUID and can define its behavior using Mockito's well-known when().thenReturn() stubbing setup.

As an alternative, we could also manually call .close() inside @AfterEach.

The same is true when we write a test that includes mocking LocalDateTime.now():

@Test
void shouldIncludeCurrentTimeWhenCreatingANewOrder() {
  try (MockedStatic<LocalDateTime> mockedLocalDateTime = Mockito.mockStatic(LocalDateTime.class)) {
    mockedLocalDateTime.when(LocalDateTime::now).thenReturn(defaultLocalDateTime);

    Order result = cut.createOrder("MacBook Pro", 2L, "42");

    assertEquals(defaultLocalDateTime, result.getCreationDate());
  }
}

@Test

void shouldIncludeCurrentTimeWhenCreatingANewOrder() {

try (MockedStatic<LocalDateTime> mockedLocalDateTime = Mockito.mockStatic(LocalDateTime.class)) {

mockedLocalDateTime.when(LocalDateTime::now).thenReturn(defaultLocalDateTime);

Order result = cut.createOrder("MacBook Pro", 2L, "42");

assertEquals(defaultLocalDateTime, result.getCreationDate());

}

Mocking Static Methods With Method Arguments

Both mocking examples above were using Java's method reference. That's a convenient way to write compact lambda expressions by referring to an existing method. However, this doesn't apply to mocking every static method.

Let's use the following MyUtils class as an example:

public class MyUtils {

  public static String getWelcomeMessage(String username, boolean isCustomer) {
    if (isCustomer) {
      return "Dear " + username;
    } else {
      return "Hello " + username;
    }
  }
}

public class MyUtils {

public static String getWelcomeMessage(String username, boolean isCustomer) {

if (isCustomer) {

return "Dear " + username;

} else {

return "Hello " + username;

}

When we now want to mock the static .getWelcomeMessage() method, we can't use the method reference. Mockito's .when() takes a Verification as an argument. This is a functional interface as it has one public method: .apply().

Hence for both UUID.randomUUID() and LocalDateTime.now() we could use their method reference like.when(LocalDateTime::now).

That's not possible for .getWelcomeMessage(String username, boolean isCustomer). If we want to mock this utility method, we can write a custom lambda expression to provide a Verification:

class MyUtilsTest {

  @Test
  void shouldMockStaticMethod() {

    try (MockedStatic<MyUtils> mockedStatic = Mockito.mockStatic(MyUtils.class)) {

      mockedStatic
        .when(() -> MyUtils.getWelcomeMessage(eq("duke"), anyBoolean()))
        .thenReturn("Howdy duke!");

      String result = MyUtils.getWelcomeMessage("duke", false);

      assertEquals("Howdy duke!", result);
    }
  }
}

class MyUtilsTest {

@Test

void shouldMockStaticMethod() {

try (MockedStatic<MyUtils> mockedStatic = Mockito.mockStatic(MyUtils.class)) {

mockedStatic

.when(() -> MyUtils.getWelcomeMessage(eq("duke"), anyBoolean()))

.thenReturn("Howdy duke!");

String result = MyUtils.getWelcomeMessage("duke", false);

assertEquals("Howdy duke!", result);

}

Mocking Static Methods With Kotlin and Mockito

Let's take a look at the OrderService again, but this time we use Kotlin to implement its functionality:

class OrderService {

  fun createOrder(productName: String, amount: Long, parentOrderId: String?) =
    Order(
      id = parentOrderId ?: UUID.randomUUID().toString(),
      creationDateTime = LocalDateTime.now(),
      amount = amount,
      productName = productName
    )
}

data class Order(
  val productName: String,
  val amount: Long,
  val id: String,
  val creationDateTime: LocalDateTime
)

class OrderService {

fun createOrder(productName: String, amount: Long, parentOrderId: String?) =

Order(

id = parentOrderId ?: UUID.randomUUID().toString(),

creationDateTime = LocalDateTime.now(),

amount = amount,

productName = productName

)

}

data class Order(

val productName: String,

val amount: Long,

val id: String,

val creationDateTime: LocalDateTime

)

Mocking the static method calls also works here. To write even more idiomatic Kotlin code, we can replace the try-with-resources statement with the use function of the Kotlin standard library:

class OrderServiceKtTest {

  private val cut = OrderService()
  private val defaultUuid = UUID.fromString("8d8b30e3-de52-4f1c-a71c-9905a8043dac")

  @Test
  fun `should include random order id when no parent order exists`() {
    Mockito.mockStatic(UUID::class.java).use { mockedUuid ->
      mockedUuid.`when`<Any> { UUID.randomUUID() }.thenReturn(defaultUuid)
      val result = cut.createOrder("MacBook Pro", 2L, null)
      assertEquals("8d8b30e3-de52-4f1c-a71c-9905a8043dac", result.id)
    }
  }
}

class OrderServiceKtTest {

private val cut = OrderService()

private val defaultUuid = UUID.fromString("8d8b30e3-de52-4f1c-a71c-9905a8043dac")

@Test

fun `should include random order id when no parent order exists`() {

Mockito.mockStatic(UUID::class.java).use { mockedUuid ->

mockedUuid.`when`<Any> { UUID.randomUUID() }.thenReturn(defaultUuid)

val result = cut.createOrder("MacBook Pro", 2L, null)

assertEquals("8d8b30e3-de52-4f1c-a71c-9905a8043dac", result.id)

}

Since when is a reserved keyword in Kotlin, we have to use the backticks when stubbing the behavior.

Both mockito-kotlin and Mockk seem not to support this yet.

Refactored Alternative to Avoid Mocking Static Methods

As an alternative, let's have a look at how we can avoid mocking static methods for our OrderService. If our project uses a framework that supports dependency injection (e.g., Spring, Jakarta EE with CDI, MicroProfile, Guice), we can slightly refactor our current implementation:

public class OrderServiceRefactored {

  private final Clock clock;
  private final OrderIdGenerator orderIdGenerator;

  public OrderServiceRefactored(Clock clock, OrderIdGenerator orderIdGenerator) {
    this.clock = clock;
    this.orderIdGenerator = orderIdGenerator;
  }

  public Order createOrder(String productName, Long amount, String parentOrderId) {
    Order order = new Order();
    order.setId(parentOrderId == null ? orderIdGenerator.generateOrderId() : parentOrderId);
    order.setCreationDate(LocalDateTime.now(clock));
    order.setAmount(amount);
    order.setProductName(productName);

    return order;
  }
}

public class OrderServiceRefactored {

private final Clock clock;

private final OrderIdGenerator orderIdGenerator;

public OrderServiceRefactored(Clock clock, OrderIdGenerator orderIdGenerator) {

this.clock = clock;

this.orderIdGenerator = orderIdGenerator;

}

public Order createOrder(String productName, Long amount, String parentOrderId) {

Order order = new Order();

order.setId(parentOrderId == null ? orderIdGenerator.generateOrderId() : parentOrderId);

order.setCreationDate(LocalDateTime.now(clock));

order.setAmount(amount);

order.setProductName(productName);

return order;

}

With this approach, we outsource the creation of the orderId to another component. In addition to this, we use an overloaded version of LocalDateTime.now() that takes a Clock to request the current date & time.

This small refactoring allows us to mock both the Clock and OrderIdGenerator while unit testing our OrderServiceRefactored class:

class OrderServiceRefactoredTest {

  private OrderIdGenerator orderIdGenerator = mock(OrderIdGenerator.class);
  private Clock clock = mock(Clock.class);
  private OrderServiceRefactored cut = new OrderServiceRefactored(clock, orderIdGenerator);

  @Test
  void shouldIncludeRandomIdAndCurrentDateTime() {
    when(orderIdGenerator.generateOrderId()).thenReturn("8d8b30e3-de52-4f1c-a71c-9905a8043dac");

    LocalDateTime defaultLocalDateTime = LocalDateTime.of(2020, 1, 1, 12, 0);
    Clock fixedClock = Clock.fixed(defaultLocalDateTime.toInstant(ZoneOffset.UTC), ZoneId.of("UTC"));
    when(clock.instant()).thenReturn(fixedClock.instant());
    when(clock.getZone()).thenReturn(fixedClock.getZone());

    Order result = cut.createOrder("MacBook Pro", 2L, null);

    assertEquals("8d8b30e3-de52-4f1c-a71c-9905a8043dac", result.getId());
    assertEquals(defaultLocalDateTime, result.getCreationDate());
  }
}

class OrderServiceRefactoredTest {

private OrderIdGenerator orderIdGenerator = mock(OrderIdGenerator.class);

private Clock clock = mock(Clock.class);

private OrderServiceRefactored cut = new OrderServiceRefactored(clock, orderIdGenerator);

@Test

void shouldIncludeRandomIdAndCurrentDateTime() {

when(orderIdGenerator.generateOrderId()).thenReturn("8d8b30e3-de52-4f1c-a71c-9905a8043dac");

LocalDateTime defaultLocalDateTime = LocalDateTime.of(2020, 1, 1, 12, 0);

Clock fixedClock = Clock.fixed(defaultLocalDateTime.toInstant(ZoneOffset.UTC), ZoneId.of("UTC"));

when(clock.instant()).thenReturn(fixedClock.instant());

when(clock.getZone()).thenReturn(fixedClock.getZone());

Order result = cut.createOrder("MacBook Pro", 2L, null);

assertEquals("8d8b30e3-de52-4f1c-a71c-9905a8043dac", result.getId());

assertEquals(defaultLocalDateTime, result.getCreationDate());

}

We can now use standard Mockito functionality to mock the behavior of our external components during the test.

Remember: Having access to a tool does not mean you should always use it.

The refactored example should give you valuable hints on how to work around mocking static calls. If there is still the need to mock them, you don't need to include PowerMock, as Mockito now supports it.

Are you looking for further practical resources on Mockito? Consider enrolling in my Hands-On With Mockito Online Course to learn the ins and outs of the most popular mocking library for JVM applications.

You can find related Mockito articles here:

The source code for this Mockito example is available on GitHub.

Have fun mocking static method calls with Mockito,

Philip

Tweet 0

Share 0

[…] though Mockito is able to mock static method calls and with deep mocking, we could keep the stubbing setup lean, we should always […]

Gives error –

org.opentest4j.AssertionFailedError: Expected :8d8b30e3-de52-4f1c-a71c-9905a8043dac Actual :null-null-null-null-null

How to solve?

rieckpil says:

February 23, 2021 at 1:29 pm

Hi Abel,

what exactly did you try to run?

Log in to Reply
Mahmoud Shereif says:

May 19, 2021 at 7:28 pm

I’m getting this too

Log in to Reply
- Mahmoud Shereif says:
  
  May 19, 2021 at 7:31 pm
  
  I have tried this tutorial code.
  Also it works fine with LocalDateTime
  
  Log in to Reply
  - rieckpil says:
    
    May 19, 2021 at 7:37 pm
    
    Hi Mahmoud,
    
    can you upload a minimal reproducible example to GitHub and send me the link? Without any further information, it’s quite hard to help.
    
    You can also check the source code for this blog post on GitHub where the tests are constantly executed and green.
    
    Kind regards,
    Philip
    
    Log in to Reply
    - Mahmoud Shereif says:
      
      June 28, 2021 at 9:55 pm
      
      Hi Philip,
      After investigation this is because I’m using JDK 1.8 after upgrading to JDK 11 it runs without issues
    - rieckpil says:
      
      June 29, 2021 at 5:36 am
      
      Hi Mahmoud,
      
      thanks for coming back and reporting what fixed your issue. I’ll take a look at the example with JDK 1.8
    - rieckpil says:
      
      July 15, 2021 at 5:18 am
      
      As a short update: The implementation of UUID.toString() changed between Java 1.8 and 11. With Java 1.8. the toString() method uses another method of UUID which returns null when we statically mock the entire class. With Java 11 it doesn’t use any internals anymore and hence we can safely call toString() of the mocked UUID class.

Hello and thanks for the example.

I am interested in mocking multiple static methods for the same test, using the aforementioned technique. Is there a better way to do it than using a try inside of a try?

rieckpil says:

March 4, 2021 at 2:00 pm

Hi bilbo,

you can put multiple declarations inside one try block, like
try (MockedStatic mockedUuid = Mockito.mockStatic(UUID.class); MockedStatic mockedLocalDateTime = Mockito.mockStatic(LocalDateTime.class)) { }

Let me know if that helps,
Philip

Log in to Reply
- bilbo says:
  
  March 4, 2021 at 3:11 pm
  
  Thanks a lot for your answer rieckpil.
  
  I already tried that. My problem is that i am doing multiple tests, in which i use the same mock of static methods, so i need in every test to use these declarations again.
  
  So i was trying to find a way to declare these mocks in the beginning of the class, so i don’t use the same block of code again and again.
  
  Thanx anyway for your help.
  
  Log in to Reply
  - rieckpil says:
    
    March 4, 2021 at 4:16 pm
    
    For this scenario you could define all your static mock as part of @BeforeAll (without any try-with-resources statement) and close them manually using .close() inside @AfterAll. It’s important to close them as they will otherwise remain active on the current thread.
    
    Log in to Reply
    - bilbo says:
      
      March 4, 2021 at 4:34 pm
      
      OK i will try that.
      
      Thans Philip 🙂

Hey! May i ask if you know whether it is possible to mock as static also private methods, using Mockito?

rieckpil says:

March 23, 2021 at 8:24 am

Hi bilbo2,

it’s not possible to mock private methods with Mockito. You can find further information at this Stack Overflow question.

Kind regards,
Philip

Log in to Reply
- ravi says:
  
  April 8, 2021 at 7:29 am
  
  return webClient.get() .uri(kongAPIProperties.getCashAvailabilityUri(), positionId, transId1, transId2) .attributes(clientRegistrationId(KONG_REGISTRATION_ID))
  clientRegistrationId(KONG_REGISTRATION_ID)
  
  is static method how to mock
  
  Log in to Reply
  - rieckpil says:
    
    April 8, 2021 at 6:29 pm
    
    Hi Ravi,
    
    I’m happy to help – please create a question on Stack Overflow and provide a little bit more information about your setup and what you’ve already tried. You can reply with a link to the question and I’ll take a look at soon as possible 🙂
    
    Kind regards,
    Philip
    
    Log in to Reply
    - ravi says:
      
      April 16, 2021 at 6:38 am
      
      public class KongAPIService {
      // ... }
      
      Update from Philip: Please don’t paste large code snippets here – please read my comments carefully.
    - rieckpil says:
      
      April 16, 2021 at 8:16 am
      
      Hi Ravi,
      
      I’m happy to help – could you please either create a GitHub issue or a Stack Overflow question and send me the link as a reply to this comment? Please also add your existing test setup and further information about your project (e.g. dependency version, etc.).
      
      The functionality of my blog’s comment section is quite limited to properly paste large code examples and seamlessly interact.
      
      Kind regards,
      Philip
    - ravi says:
      
      April 20, 2021 at 8:24 am
      
      https://stackoverflow.com/questions/67174216/how-to-test-given-class-having-static-method-using-mockito
    - rieckpil says:
      
      April 20, 2021 at 11:35 am
      
      Thanks, Ravi – let’s continue the discussion on Stack Overflow.
    - ravi says:
      
      April 21, 2021 at 4:08 am
      
      I have added my test case also
    - ravi says:
      
      June 16, 2021 at 1:04 pm
      
      https://stackoverflow.com/q/68002163/15365716
      Above the link of stack overflow question related to test
      can you help I attach two screenshot . one is business class and one is its test class.
    - rieckpil says:
      
      June 16, 2021 at 1:19 pm
      
      Hi Ravi,
      
      sure – I’m happy to help. Let’s continue the discussion on Stack Overflow.
      
      Kind regards,
      Philip
    - ravi says:
      
      June 17, 2021 at 4:49 am
      
      Note from Philip: removed large code block
    - rieckpil says:
      
      June 17, 2021 at 5:01 am
      
      Hi Ravi,
      
      please paste the code example on Stack Overflow and not here as a comment. The code formatting functionality of my blog’s commenting system is limited 🙁
      
      Kind regards,
      Philip

Hi,
Just to share that if like me, you decide to use version 3.4.0, you might get the error reported here https://github.com/mockito/mockito/issues/1967

rieckpil says:

July 17, 2021 at 10:57 am

Thanks for the hint Atem 🙂

With a Mockito version > 3.4.0 everything works for you?

Log in to Reply

Beginner-Friendly Spring Boot Testing Course

Concise, beginner-friendly, easy-to-follow, hands-on, simple vocabulary to kickstart your Spring Boot testing success.

The course has been recently updated to Spring Boot 3.0 and Java 17

Share this Article

Tweet 0

Share 0

Recently Published

September 26, 2022

Latest Conference Talk

How Fixing A Broken Window Reduced Our Build Time by 50%

Things I Wish I Knew When I Started Testing Spring Boot Applications

Quicklinks

Spring Boot & AWS

All you need to know to get a Spring Boot application into production on AWS

Infrastructure Setup (ECS Cluster, SQS, RDS, etc.) with the AWS CDK v2
CI/CD Pipeline with GitHub Actions
Monitoring and Alerting with CloudWatch
Integrating Cognito, SQS, RDS, CloudWatch, etc. with Spring Boot & Spring Cloud AWS
Cloud-native Microservice patterns and best practices
New: Java 17, Spring Boot 3.0, Spring Cloud AWS 3.0

Join our Stratospheric mailing list to get a 30% discount.

Kickstart Your Spring Boot Testing Success

Enroll for only 1€ (instead of 39€) during the Primer 2.0 launch window.

Recently updated to Spring Boot 3.0 and Java 17.

Enroll Now

Mocking Static Methods with Mockito (Java & Kotlin)

Required Mockito Maven Setup

Mocking Static Methods With Java

Mocking Static Methods With Method Arguments

Mocking Static Methods With Kotlin and Mockito

Refactored Alternative to Avoid Mocking Static Methods

TESTING STARTER COURSE

TESTING DEEP-DIVE COURSE

QUICKLINKS

RECENTLY PUBLISHED