(Original keynote slides can be found at https://github.com/Endran/PublicSlides) For years the industry standard of mocking on the JVM has been Mockito. Mockito is a wonderful library that really speeds up your testing by allowing you to create mocks in a very simple way. That being said, it does have its drawbacks, for which different strategies need to be deployed to keep your code testable. The main drawbacks are statics and finals. Final classes cannot be mocked, nor final methods, and also static methods are a no-go. To work with these type of things we need to wrap it, and copy the signature in a non final, non static way. I have a great adversity against statics, I've devoted an entire post about it, in short; It hides dependencies and brings so little convenience at the costs of its drawbacks. Finals on the other hand have purpose, it helps messaging the goal of a class or method. Java is one of the few languages where classes and methods are open/virtual by default and have to be closed/final by explicit action. In (for example) Kotlin, everything is final by default, if you do not want something to be final, you should use the open keyword. No matter if you follow the principle of making things final, static or not, if you are using Mockito the decision has been made. This mocking framework demands that everything is non-final, demands that everything is designed to be extended, since it might need to be mocked away. We should be able to improve upon this, and by the name of this post, you should be able to guess which framework will save the day. JMockit will help us with our impediments, and will give some other nifty benefits as well!

1. Mockito vs JMockit,
battle of the mocking
frameworks
The art of pretending

2. 2

3. In all it’s glory
• Has been around since 2008
• Is the industry standard ever since
• In 2013 more then 30.000 Github project
• More popular then Spring and Guava
• Most distinguishing feature
• Verify the behaviour of the SUT without
establishing expectations beforehand
3

4. Mockito in action
4

5. Mockito in action
5

6. Mockito in action
6

7. So for, so good
• Arrange, Act, Assert
• Mock any class, interface, method
• No need for introducing test interface
shims
• Declarative style for setting up behaviour
• Declarative style for verifying behaviour
• …
• In the happy flow
7

8. This gun’ be good
8

9. This gonna be good
• Mocking void methods
• Mocking finals
• Mocking statics
• Verifying constructors
9

10. This gonna be good
• Make a test shim
• Extend the class and scoop the methods
• Make an adapter or facade
• Why aren’t they using interfaces in the
first place
• The final keyword should be banned
• Let’s agree not to test this
• Ahh.. let’s use
PowerMockito!
10

11. JMockit
11

12. JMockit in action
12

13. JMockit in action
13

14. JMockit in action
14

15. JMockit in action
15
• Expectations are like Mockito.when(…)
• Verifications are like Mockito.verify(…)

16. JMockit in action
16
• Uniform notation for
• Primitives
• Complex objects
• Exceptions
• Custom Answers

17. JMockit in action
17

18. Annotations - With great power…
18
• @Injectable
• Single mock instance
• @Mocked
• Entire class mock (at bytecode level)
• @Capturing
• Any derived instance and subclass will be a class mock
• @Tested
• System under test
• Tries to satisfy Constructor, @Autowired, @Injectable

19. … comes great responsibility - Scoping
19

20. Legacy mock injection
20

21. Real world examples
21
java.lang.RuntimeException: Method getWindow in android.app.Activity not mocked. See
http://g.co/androidstudio/not-mocked for details.
at android.app.Activity.getWindow(Activity.java)
at android.support.v7.app.AppCompatDelegate.create(AppCompatDelegate.java:117)
at android.support.v7.app.AppCompatActivity.getDelegate(AppCompatActivity.java:456)
at android.support.v7.app.AppCompatActivity.onCreate(AppCompatActivity.java:59)
at ExampleActivity.onCreate(ExampleActivity.java:15)
at ExampleActivityTest.
shouldCommitFragment_whenOnCreateIsCalled(ExampleActivityTest.java:9)

22. Real world examples
22
akka.actor.ActorInitializationException: You cannot create an instance of
[com.cc.LoggingHandler] explicitly using the constructor (new). You have to use one of
the 'actorOf' factory methods to create a new actor. See the documentation.
at akka.actor.ActorInitializationException$.apply(Actor.scala:173)
at akka.actor.Actor$class.$init$(Actor.scala:436)
at akka.actor.UntypedActor.<init>(UntypedActor.scala:97)
at com.cc.LoggingHandler.<init>(LoggingHandler.java:14)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at …

23. Real world examples
23

24. 24
JMockit

25. 25
JMockit

26. JMockit’s Advantages
• Mockito’s distinguishing feature covered by
JMockit
• Verify the behaviour of the SUT without establishing expectations
beforehand
• No need for special test runners
• No limit on testing statics, finals,
constructors and whatnot
• No limitations/anomalies in your code due
to the test framework
26

27. JMockit’s Disadvantages
• Risk of introducing in your code
• Static methods
• Not using dependency injection
• Need to get accustomed to new mocking
framework
• Mockito’s error messages are more
explicit
• Mockito forces proper dependencies
27

28. Some figures
• Github grade and maven dependencies
• Mockito: 131.525
• JMockit: 3.058
• First mentioned - first release:
• Mockito: 2008 - 2008
• JMockit: 2006 - 2012
• Both under constant development
28

29. Read more
• Official pages:
• Mockito: http://mockito.org/
• JMockit: http://jmockit.org/
• My blog:
• www.endran.nl/blog
• Mockito vs JMockit, battle of the
mocking frameworks
• Death to statics
29

30. 30
“I Don’t Always Test My Code. But When I Do, I Do It In
Production.”