User:Pratik5791/JMock

jMock is an Open source Mocking Framework, which aids in writing Unit Tests for Java code. In Object-oriented programming, objects interact with each other. Mock objects can be used to design and test these interactions.

jMock provides APIs which can be used to create Mock Objects for external dependencies in your code. The programmer can then specify relevant expectations on Mock Objects and/or stub required behaviour. The mock implementations are dynamically generated at runtime and the methods are matched by the method name and parameters using Reflection. This makes it relatively easier for the programmer to write tests before writing the code itself (Test-Driven Development) because Mock Objects do not have to be created, they are generated by the Framework.

Brief History
Before the concept of Mock Objects came into existence, there was a widespread practice of having ‘getter’ methods in objects to assist testing. This was a blatant violation of Encapsulation and hence against the Object Oriented Design Principles. A London based Software Architecture group discussed this issue back in 1999. The solution which emerged as part of the discussion was to use Dependency Injection instead of relying on ‘getter’ methods. In an attempt to have a solution which is Object Oriented a team at Connextra started injecting dependency to objects rather than using ‘getter’ methods. They named this whole concept ‘mock’.

After working further on the 'mock' concept and improving it, the initial Mock Objects library was released. This was a very basic version and since Java did not had a good support for reflection back then, the programmer had to do many things in order to add a new test case with mock objects and have expectations specified on them. This discouraged some of the programmers from using this concept.

Later on, the concept was implemented in Ruby programming language which had a good support for reflection. The programmer could now add tests with ease. This was implemented in Java (JDK 1.3) with the help of Proxy type. After further improvements like those in failure reporting a new version was released – Dynamock.

Dynamock had some limitations too, which were discovered during the course of its use. This led to the development and release of the first version of jMock with some major changes like improving readability of test code by using daisy chaining of methods, reducing size of APIs, etc. There is also an implementation of jMock in C# - NMock.

The developers behind the jMock project are Steve Freeman, Tim Mackinnon, Nat Pryce, Mauro Talevi and Joe Walnes.

The latest version JMock 2.6.0 was developed in 19 December, 2012.

jMock Layered Architecture
The paper - Evolving an Embedded Domain-Specific Language in Java by Steve Freeman and Nat Pryce explains the different layers of jMock with diagram. There are two layers:

1. Builder Layer

Builder Layer is composed of the Public APIs of jMock.

2. Interpreter Layer

At some point during the execution of the Unit Test, a method might be invoked on a Mock Object. The interpreter Layer receives this method invocation. Each expectation specified on a Mock Object is created and stored as an Invokable in the Interpreter Layer. So the Interpreter Layer will try to find a match for the method invocation which happened during the execution of the test case in one of the Invokables. If a matching Invokable is found, the call is transferred to the Invokable’s Stub. If no match is found the test case will fail. Once the test execution ends, the Interpreter layer verifies all the Invokables to make sure none of the expectations has been missed out.

The Matcher is responsible for matching an invokable with a Mock Object method invocation. In order for the invocation to match an Invokable all the constraints in the invocation (values of arguments, order of method invocation etc.) should match the Invokable. The matcher accomplishes this task with the help of the Constraint object. The Matcher knows about the Constraint objects and allowed values.

Example
Consider the method 'IndexDocuments(…)' in 'DocumentIndexer' class, which indexes all the documents provided by the IDocumentProvider instance - FetchDocuments method; using an IIndexWriter instance - Index(…) method.

Here, IIndexWriter and IDocumentProvider are external dependencies for which we have to create Mock objects. On these Mock Objects we specify relevant expectations. In this case we expect that IDocumentProvider FetchDocuments method and IIndexWriter Index(…) method is invoked. One way to write a Unit Test for IndexDocuments(…) method with the above mentioned Mock Objects and expectations, making use of jMock is as follows:

The test class DocumentIndexerTest extends the jMock class MockObjectTestCase which extends the JUnit TestCase class. MockObjectTestCase class provides many methods which can be used for specifying different expectations and it also handles the verification of these expectations. By inheriting the MockObjectTestCase class, the test class is able to reuse all these implementation.

The lines 4 – 6 sets an expectation on the indexWriterMock object Index(…) method that this method is invoked exactly once during the test run and it takes an argument which can be anything of type List. The lines 7-9 sets an expectation on the documentProviderMock object FetchDocuments method that this method is invoked exactly once during the test run. The verification of these expectations are handled by the base class MockObjectTestCase as explained earlier. If any of these expectations are not met while running the test, the test fails and the programmer is presented with a detailed error message and call stack.

jMock has tried to adapt a syntax which makes it easier to understand what the test case is doing just by reading the code. The idea is to have test cases which also acts as its documentation. This approach of jMock is most visible in defining expectations and is achieved by chaining of methods.

Expectation Structure:

jMock also allows the programmer to have Constraints on the specified expectations in an attempt to make it more suitable for the test. The programmer can have a constraint on the number of times a method has to be invoked, the order in which certain methods has to be invoked, the arguments with which a method has to be invoked and so on. For example, the following code places two constraints on the expectation, first the method has to be invoked exactly once and second the arguments of the method can be anything of type List.

This provides the programmer with more options so that he can focus more on the functionality being tested. jMock also allows the programmer to define his/ her own constraints too.

Advantages

 * Mock objects are easy to define and the flow of the programming is not affected.
 * It is compatible with different testing frameworks.
 * Syntax for specifying expectations are readable and acts like a documentation for the test.
 * It is extensible.
 * Programmer does not have to worry about the verification of the expectations as it will be handled by the Framework.

Disadvantages

 * The user has to learn how to mock an API. Stub objects are comparatively easy to use.
 * The user has to get used to the syntax for specifying expectation.
 * Support of a good IDE might be required in order to have the IntelliSense while writing code for specifying expectations with complex constraints.