Enable mocking static methods in Mockito

[mockitoguy]

Static methods mocking with Mockito

This is a placeholder ticket for enabling mocking static methods in Mockito. Example action items that are totally negotiable and can ran in parallel. We're looking for someone who can lead this effort.

• Research + discuss whether it is a good idea to enable static methods mocking in Mockito. The theory is that it is useful for legacy code, which is most code in the world.
• Research on how other mocking frameworks do that and whether it is considered useful feature for their users.
• Design and present for discussion an API for static mocking (slightly relevant ticket: Support lambda when syntax #643)
• Work with @raphw / ByteBuddy to come up with hacky prototype (the hackier, the better!)
• Mold the prototype with the API, remove enough rough edges so that the feature is good enough for incubating rollout
• SHIP IT!

[TimvdLippe]

I am torn on this one. If we provide this possibility, we might invite developers into bad practices. Every time a developer uses this feature, it should be very explicit that it is bad practice imo. Would it be possible to come up with a solution that is clear on this front, but still allows the developer to opt-in?

[mockitoguy]

Great feedback. That's the first thing to figure out when working on this ticket :)

[raphw]

the way I saw mocking of static methods for myself was to only mock calls to static methods that happen within a mock. This would be useful, for example, for implementing spies in a situation like:

class Foo {
  String bar() { return Util.makeString(); }
}

With Mockito, I would like to see something like:

Foo foo = spy(new Foo());
doReturn("foo").when(foo).invokesStatic(Util.class).makeString();
assertThat(foo.bar()).isEqualTo("foo");

What do you think? As for a hack, I am missing a component in Byte Buddy which I was supposed to write for a customer at some point what did however not pull through. I am not currently in a position to spend so much time to build this component, due to my personal situation, but please prototype away. I think the API and spec work is crucial to make this a success.

[mockitoguy]

Great feedback! Thank you Rafael for sharing your thoughts.

Is the component you mentioned a lot of work in ByteBuddy? Is this something that we can ask the community to help out or you're the best person to take on?

I'd rather see more robust API but your API idea is certainly workable. Mocking statics should be rare and our API should be optimized for common use cases and not edge/rare cases. We can always iterate based on feedback :)

Here's my preference as of today:

//setup
mockStatic(Util.class);

//then
doAnswer().when(() -> Util.foo());
when(Util.foo()).thenReturn("foo");
verify(() -> Util.foo());
verify(never(), () -> Util.foo());

If we choose to support mocking static methods, I'd rather offer API that is robust enough to support all kinds of use cases. I like when tools are separated from policies and are opinionated but not dogmatic :) If we think that mocking static is disgusting, we can ship it in a different jar called "mockito-for-crappy-code", loosely following @TimvdLippe idea.

The main use cases for mocking statics I see are:

• legacy code (I really, really want to write a unit test but I don't dare to change some ancient ugly code)
• dealing with some awkward static 3rd party APIs. This scenario is currently workable by developing some injectable API layer on top of 3rd party statics. However, the workaround could be cumbersome and can spoil the clarity of codebase.

Without addressing above 2 use cases, developers around the world will be looking for help in tools like Powermockito, and such.

The biggest downside of offering static mocking is making it too easy to test crappy, procedural code full of static methods. We would remove a motivation to refactor the code into clean OO / DI.

[TimvdLippe]

Should we also send out a Tweet to gather some community insights?

[tmurakami]

If this feature uses the Java Instrumentation API, it will not work on Android devices, so it might confuse Android developers.
If so, I think it should not be integrated into the mockito-core artifact.

[bencampion]

I came across this issue by chance (I was just curious to know what you were planning for Mockito 3), but I'd like to share my experiences of working with static method mocking.

I used to work on several large codebases that made extensive use of static methods and used PowerMock (and PowerMockito) heavily for testing. My main memories of that time were that the tests were really slow to run (in some cases tests that use PowerMock were literally ten times slower than those that didn't) and that we ultimately had to remove all usages of PowerMock because it wasn't compatible with newer versions of Java. I also recall there being incompatibilities with some libraries were using that required special setup in the tests to make them pass, although I no longer remember the details of that.

I can understand concerns about promoting bad code, but as a Mockito user I'd be more worried about the impact on performance and robustness. Not all of the code we were using PowerMock for was legacy. Some of it was new code written by an inexperienced team (of which I was part of) and knowing that Mockito devs disapproved of our design patterns probably wouldn't have made any difference.

This was a few years ago now and techniques for mocking static methods may have improved significantly since then. If you think there's a performant and robust way to implement this feature then I'd welcome it (even though I'd hope I never have to use it).

[mockitoguy]

Really good feedback, thank you guys. I helps us make good decisions about the features/API we plan.

[szpak]

In my opinion in general testing static methods is a bad idea and it would be better to refactor the code, however, sometimes it's something that is needed. For instance, testing a default method given() in mockito-java8 interface delegating to a static method in BDDMockito.given() the easiest solution I see is to generate in runtime a list of static methods in BDDMockito and execute parameterized test for every of them verifying that a corresponding method in WithBDDMockito interface delegates to it with proper parameters. In that case static method mocking would be beneficial. Maybe I will wait for PowerMockito for Mockito v2 to test Mockito itself...

Alternatively I would need to play with AOP and load-time weaving, code generation in runtime or some other not very pleasant to use technique (unless you have some good ideas how to do it easier).

[mockitoguy]

@szpak, thank you for the feedback! Interesting use case.

I think we all agree that mocking statics is a bad practice and an anti-pattern in general. The question is whether we enforce the "no mocking statics" policy (e.g. not offer the feature in the tool) or let the user decide to enforce it or not (e.g. offer the feature).

[Krazybug]

Please, consider the legacy code issue. Sometimes you don't have any choice.
Enforcing or not a practice shouldn't be the decision of a framework but of the team.
Also, for now, we're using Powermock as a workaround for this need but it's not compliant with the last versions of Mockito. We're blocked with 1.9.x version of Mockito.
It's another good reason to get this feature: Limit dependencies.

We already need all these libraries to get decent unit test in pure Java world:
JUnit,
JUnitParams as Junit Parametrized are awfull
AssertJ for expressive and clear assertions
Mockito ... and Powermock

and i shouldn't mention other peripheral libraries:
DBUnit,
SpringDBunit
JBehave, JGiven for BDD style ....

Then you can write all your testing stuf in Groovy and you only need ... Spock

Please! Let user choose. Othewise, why did you provide private method mocking in the recent versions athough it's considered as a "bad" practice for TDD purists ?

Finally, thanks for your great work. Mockito is really a nice framework

[jlink]

Mocking static methods is a different use case, maybe that means it should be a different tool.

Answer the following questions (to yourself):

• Do you want to support a double tool in the long term?
• Does it use the same set of dependencies and only those?
• Does mocking static methods fall nicely into the current design?

If you answer all 3 with "Yes", then go ahead. If at least one is a "No" consider the alternatives:

• Build a Mockito extension
• Build a new tool and call it Mackarita
• Leave the other tool to someone else

Just my two cents.

[karollewandowski]

I agree with most of you and think that mocking static methods is not a good idea.
If some method uses static method provided by legacy library/framework, then it can be easily wrapped in object and provided as mockable dependency. It's not perfect solution, but is educational - shows developers that writing too complex static util methods hurts and makes code hard to test. If Mockito had such feature, many of developers would consider it as acceptable practise and produce bad code.
Another issue is parallel tests execution. In my current project we used to use PowerMockito to mock static methods and after some time our tests started to fail because of concurrency issues:

1. Thread A mocked static method X.y and stopped.
2. Thread B mocked static method X.y and stopped.
3. Thread A was awaken and run test - it failed because thread B overwritten static method's behaviour expected in test run by A.

We ended up with wrapping static methods in injectable objects and removed PowerMockito from project dependencies.