Mock object
A mock object (also a dummy , from English to mock , 'pretend something') is a part of the program in software development that is used as a placeholder for real objects to carry out module tests . Such aids are colloquially called mocks .
It is not always possible or desirable to test a single object in complete isolation. If the interaction of an object with its environment is to be checked, the environment must be simulated before the actual test. This can be cumbersome, time-consuming or only possible to a limited extent or not at all.
In these cases mock objects can help. Mock objects implement the interfaces through which the object to be tested accesses its environment. They ensure that the expected method calls are made completely, with the correct parameters, and in the expected order. The mock object does not return any real data, but rather values specified beforehand to match the test case. The mock object can thus be used to simulate a certain behavior.
commitment
Specifically, mock objects make sense if the "real" object
- should not be damaged by "unexpected errors" during the tests,
- provides non-deterministic results (e.g. the current time or the current temperature),
- Causes difficulties in preparation or during execution (e.g. when testing user interfaces),
- Should show behavior that is difficult to trigger (e.g. a network error),
- is slow or very complex (e.g. a complete database that would have to be initialized before each test),
- does not yet exist (e.g. in larger software or hardware development projects),
- Would have to provide information and methods solely for test purposes (and not for its actual task),
- initiates processes that cannot be reversed or are difficult to undo (e.g. deleting files from a network resource).
In contrast to module tests, integration tests test the entire system from interconnected components ( units ). Usually, mock objects are no longer required.
Different types
To isolate test objects during the module test, auxiliary objects can be implemented and used as substitutes . The following auxiliary objects are known:
- Dummy
- An object that is passed in the code but not used. Is used to fill parameters with values.
- fake
- An object with implementation. However, the implementation is limited, which means that it cannot be used in the production environment. A typical example of a fake is a database that only temporarily holds data in memory.
- Stub
- An object that delivers the same output when a certain method is called, regardless of the input.
- Mock
- An object that delivers a defined return for previously determined function calls with certain transferred values. A mocking framework is usually used to create the mock object .
- Spy
- An object that logs calls and transferred values and returns them if necessary. Fake, stub or mock objects are expanded into a spy. Alternatively, a decorator can be used.
- Shim, Shiv
- A library that intercepts the request to a programming interface and handles it itself (e.g. using a fake, stub or mock object), changes the parameters passed or redirects the request.
See also
- Mocking Framework - Frameworks that simplify the creation of mock objects.
literature
- Vincent Massol, Ted Husted: JUnit in Action . Manning, 2003, ISBN 1-930110-99-5 ( chapter on mock objects; PDF file; 842 kB).
- Johannes Link u. a .: Software tests with JUnit. Test Driven Development Techniques . 2nd Edition. dpunkt, 2005, ISBN 3-89864-325-5 ( chapter on mock objects; PDF file; 219 kB).
- Frank Westphal: Test-driven development with JUnit and FIT . dpunkt, 2005, ISBN 3-89864-220-8 ( frankwestphal.de [PDF]).
Web links
- Steve Freeman: Mock Objects. August 5, 2008, accessed on April 11, 2013 (English, portal to mock objects).
- Robert Mühsig: HowTo: UnitTests and introduction to mocking with Rhino.Mocks. Code Inside, August 5, 2008, accessed April 11, 2013 .
Individual evidence
- ↑ Martin Fowler: Mocks Aren't Stubs. January 2, 2007, accessed August 5, 2013 .