JMockit is a Java mocking framework that provides tools for isolating code dependencies during unit testing. It uses bytecode instrumentation to remap classes at runtime, allowing final classes and static methods to be mocked. Expectations define mock object behavior, and verifications ensure mocks are used as expected. JMockit provides a more powerful and flexible mocking approach than alternatives like Mockito through its instrumentation and expectations/verifications APIs.

1. Mocking with JMockit Mario Peshev DevriX CTO, SCJP Consultant, Trainer http://www.linkedin.com/in/mpeshev http://devrix.com

2. Contents What is Mocking Where to use mocking JMockit introduction Expectations and Verifications Annotations and Coverage Comparison of mocking frameworks

3. What is Mocking Isolated class or method testing Ignore dependencies of related classes when not necessary Simplify testing environment by providing empty proxies instead of complex logical units

4. What is Mocking (2) A mock object represents a surreal interface or a class with modified output Code behind is being skipped to reduce the effort of initialization before running a test case

5. Mocking Scheme DB Server Web Server Application with dependencies MOCKED

6. Why mock? Replace all collaborators with mocks Avoid the use of Context with specific setup Test only the core functionality of a class or a method

7. Mocking advantages Remove dependencies from external libraries and servers: Databases Web servers Sockets Web services Less time for writing unit tests for legacy code

8. How does mocking work Two general types of mocking Proxy based easymock, jmock Class loader remapping jmockit, powermock

9. Proxy based Proxy based approach relies on reflection Java Reflection API is a powerful toolset to inspect Java code at runtime Different structures could be explored – classes, interfaces, fields, methods Even private methods could be called

10. Proxy based (2) Reflection provides mechanism to create objects, invoke methods and access get/set field values and return types Interfaces could be implemented dynamically via java.lang. reflect.Proxy Proxy return values could be defined

11. Class loader mapping This method relies on the Instrumentation API Instrumentation API is a set of features since Java 5 It allows remapping of the classes to be called by the VM

12. Instrumentation API In package java.lang.instrument Provides services that allow Java agents to instrument programs running on the JVM Instrumentation does direct bytecode modification of methods and classes Uncatchable by debuggers

13. Instrumentation API (2)

14. Remapping example We have a Book class to define Book model behavior to a model. We need to separate DB logic dependences from the Book So we define BookMock class and Instrumentation remaps VM links from Book to BookMock.class

15. JMockit

16. JMockit Open source mocking library Under MIT license Collection of tools to be used in testing environment together with JUnit or TestNG framework Bytecode modifications done at runtime through internal ASM library

17. JMockit Components 6 components in the toolkit: JMockit Core JMockit Annotations JMockit Expectations JMockit Coverage JMockit Hibernate Emulation JMockit AOP

18. JMockit vs. the World JMockit is far more complex, but more powerful than the other mocking frameworks It allows mocking of static methods and final classes http://code.google.com/p/jmockit/wiki/MockingToolkitComparisonMatrix

19. JMockit inside

20. Expectations API Provides a record-replay model Set one or more expectations Define a real sample code using directly or not the mocked object Automatic verification of all expected invocations is transparent with JUnit/TestNG connection

21. Expectations API (2) Mock types could be defined as instance fields of the test class or of an Expectations anonymous subclass inside the recording phase new Expectations() { ClassToBeMocked mock; { … } }

22. Expectations API (3) Expectations could be specified of any kind of method invocation Interfaces, abstract classes, concrete final or non-final classes, static methods, constructors Private methods and constructors could have expectations too

23. Expectations API (4) By default, all expectations are strict For each expectation a matching invocation is expected and in the same order If additional invocation to mocked type/instance is detected, assertion error will be thrown too Non-strict expectations could be defined – singular or in a specific block

24. Expectations API (5) A non-strict expectations could be invoked any number of times (0…N) and in arbitrary order Unexpected invocations don’t cause errors to the test Mocked objects could be passed as test method parameters (TestNG included)

25. Expectations Sample public class MockNoInterfaceClassTest { static class User { String name() { return "joe"; } } @Mocked User user; …

26. Expectations Sample (2) … @Test public void mockNoInterfaceFinalClass() { new Expectations() { { user.name(); returns("fred"); }}; assertEquals("fred", user.name()); } }

27. Verifications API Additional phase for verify to the record-replay model All other invocations in the test can be verified to have occurred (or not) after the replay phase It is possible to not have expectations but verifications only

28. Verification API (2) Doesn’t make sense when we have 100% strict expectations However, when we have mocked types with non-strict expectations, this is where we could make sure invocations are being called as required

29. Verification Demo static class UserService { void populateUser() { User user = new User(); user.setName("fred"); user.setAge(31); } } @Mocked User user; …

30. Verification Demo (2) … @Test public void verifyInternalMethods() { new UserService().populateUser(); new FullVerificationsInOrder() { { User user = new User(); user.setName("fred"); user.setAge(withAny(1)); } }; }

31. Verification Types InOrder The order of invocations in the Verification block has to match the original order Full Guarantees that _all_ invocations in the replay block must be verified in verification block Could define FullVerificationsInOrder too

32. JMockit test method template @Test public void aTestMethod( <any number of mock parameters> ) { // Record phase : expectations on mocks are recorded; empty if there is nothing to record. // Replay phase : invocations on mocks are &quot;replayed&quot;; here the code under test is exercised. // Verify phase : expectations on mocks are verified; empty if there is nothing to verify. }

33. JMockit Mockups A different kind of API which adds functionality to mocking types Mock classes are defined and applied for a method or a testing class Mock methods are @Mock annotated and behavior is defined that replaces the original method body Number of invocations could be set too

34. State-oriented mocking Useful for testing the argument values instead of checking invocations Allows complex data handling and verifications Achievable with mockit.Mockup<T> generic class for mockup creation

35. Annotations Demo @Test public void mockSystemNanoTime() { new MockUp<System>() { @Mock @SuppressWarnings(&quot;unused&quot;) long nanoTime() { return 0L; } }; assertSame(0L, System.nanoTime()); }

36. JMockit Coverage Code coverage API Bytecode modification done only on runtime (constructions on demand) 1 .jar only – based on “ convention over configuration ” Automatic analyze of all classes (specific set could be defined later)

37. JMockit Coverage (2) Output could be as XHTML report or any serialized file Line-coverage and Path-coverage metrics Incremental test runner Analyze only modified local files

38. Coverage Report

39. Hibernate Emulation Designed for the speed of unit test and functionality of Hibernate-based integration tests Fake Hibernate 3 Core API Implementation O/R mapping data is ignored as well as real connections to database

40. JMockit installation Download jmockit from project homepage: http://code.google.com/p/jmockit/downloads/list Copy jmockit.jar in your Eclipse project Add the -Djavaagent=jmockit.jar (with relative or absolute path) to your JVM arguments when running Eclipse Run with JDK and not JRE

41. JMockit with TestNG For TestNG support with JMockit, the Initializer listener needs to be added -listener mockit.integration.testng.Initializer as program argument Or as a TestNG XML parameter in testng.xml:

42. Running JMockit with TestNG Eclipse Demo

43. @Mocked and @Injectable @Mocked All instances of the given class (current and future) are mocked @Injectable Only the given instance of the class is mocked

44. JMockit vs. PowerMock PowerMock is only extension to other mocking frameworks JMockit provides a new Expectations API PowerMock API is low level and requires specific API calls Methods are mocked in a declarative way with specified partial mocking

45. JMockit vs. PowerMock (2) JMockit has support for mocking equals(), hashCode() and overriden methods PowerMock uses custom class loaders which is heavy and could lead to conflicts The –javaagent approach in JMockit is simpler and safer

46. JMockit vs. Mockito Every Mockito object invocation requires a call to its mocking API (between record and verify phases) Mockito has inconsistences in the syntax used for invocation of mocked methods Mockito has different syntax for calling methods returning values and void methods

47. JMockit vs. Mockito (2) In Mockito all invocations to mock objects during the test are allowed, never expected Verification is not automatic JMockit Expectations & Verifications gives plenty of options for best combination of strict (expected) and non-strict (allowed) mock invocations

48. JMockit vs. Mockito (3) Mockito needs additional object for in order and full verifications JMockit gives a combination of VerificationsInOrder or FullVerifications (or FullVerificationsInOrder)

49. Questions?

50. DevriX Ltd Consulting services Consulting in Java/PHP related technologies, database systems and platforms: GWT Swing WordPress CakePHP Trainings Core Java Java and Database Management Swing API JEE Tools and Automation Testing Design Patterns … http://devrix.com