mock object

The term mock object is derived from the English mock, which can be translated as seeming. In software engineering, the term is used in connection with the automated testing of object-oriented software in the context of so-called unit tests. In this context, a mock object simulates the behavior of a real object. Mock frameworks such as JMock, EasyMock or RMock can dynamically generate mock objects for a specific type such as interfaces or classes. An interesting approach is the VirtualMock framework, which is aspect-oriented.

Unit tests designate parts of a test program and are by definition always fine-granular, since they are limited to the test of individual methods or components. Unit tests are integrated into the program code in the context of the software development in such a way that errors can be recognized at an early stage. Typical examples for the application of unit tests are the connection of a business logic to a database or the automated testing of input masks. Such tests with real databases or objects regarding the required functionality would be too complex and costly. At this point, mock objects are used to generate states and situations that simulate the requirements.

Designation of mock objects

In the literature, mock objects are also often compared to trunk implementations of methods, so-called stubs. Mock objects can be generally formulated however software components, which replace again for testing other components such as for example a data base completely.

Mock objects can be generated dynamically by mock frameworks such as JMock, EasyMock, RMock or DynaMock. Again, other mock frameworks such as MockCreator generate new program code. The dynamic approach has the advantage of not having to generate new program code. However, the generation of mock objects can only ever be within the scope of what is possible through the corresponding API - for example, the Java Reflection API. In addition, by using frameworks, special test cases can be specified for what calls to methods are expected for a mock object or what value the mock object should return when a particular method is called.

The practical use of mock objects must always be supported by the following prerequisites:

• a mock object and its original object must always be used in the same context,
• the mock object is used only in the test phase and must be able to be neutralized afterwards in a simple way again.

Mock objects in aspect-oriented programming

Also in the context of aspect-oriented programming these preconditions can be fulfilled simply. For this the tester must catch the call of methods of the real object which can be replaced by a mock object in the context of so-called point-cuts and replace by methods, which return results co-ordinated with the test case. The real object does not have to be completely implemented, it is simulated by the mock object. However, the methods to be replaced for the test case to be examined must be implemented in the body, otherwise the code cannot be compiled.

If the test case is now initiated, the mock aspect is set to its initial value, which emulates the behavior needed for the test case. After leaving the test case, the correct execution of the aspect ischecked from the point of view of the calling object - were the correct methods, in the intended order, with the correct parameters called. Deviations are also registered in the process. For the execution of these steps there are supporting tools - as for example the Framework VirtualMock - so that knowledge of the aspect-oriented programming languages is helpful however not absolute condition.