JMockit Framework Overview

JMockit and mocking in Java tutorial - Expectations, Verifications APIs and mocking up

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
M
O
C
K
E
D

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
"replayed"; 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("unused")
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.Initiali
zer 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