Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Mockito vs JMockit, battle of the mocking frameworks
Similaire à Mockito vs JMockit, battle of the mocking frameworks (20)
Dernier
Dernier (20)
Mockito vs JMockit, battle of the mocking frameworks
- 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
- 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
- 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
- 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
- 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 …
- 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.”
Notes de l'éditeur
- Final class wont work Final method wont work Static method cannot be mocked Thread.sleep will be executed every time
- Hint about the annotaions, details in next slides Expectations is like Mockito when, not necessary for verifications
- Times 1 is optional Thread sleep can just be mocked
- minTimes is optional. Set to 0 to be exactly like Mockito when. Expectations need to be met. Not meeting expectations will fail your test. GoogleMock users can still do their expectations beforehand, Mockito user can still do verification afterwards.
- Any mated with matching signature
- A captor is just a list with the type you want to capture. Assertions can be done in the Verifications, or outside of them. Dealers choice.
- This legacy code doesn’t have Dependency injection Just mock the constructor
- Akka provides a mechanism to create test actors and whatnot, but it also does some lifecycle methods. This unit test only tests our code, and ignores framework limitations
- Akka provides a mechanism to create test actors and whatnot, but it also does some lifecycle methods. This unit test only tests our code, and ignores framework limitations
- This is the same test as the @Capture before. Without @Capture we need to setup the entire test suite ourselves Before setup the mocks are created, after setup @Tested is created. Static constructor dependencies are resolved after the setup, before the test. Since we do not know exactly which concrete class Logger is, @Captor will mock any Logger.