CSC/ECE 517 Fall 2009/wiki 1a2rd: Difference between revisions
| Line 37: | Line 37: | ||
=== There have to be some limitations. === | === There have to be some limitations. === | ||
# Who will guard the guard?< | # Who will guard the guard?<br>Mock Objects are used for unit-testing, but who will ensure that the mock object is correctly mimicking the behavior of a real object. Care needs to be taken while implementing mock objects, if the behavior is improperly implemented then it will cause the test cases to fail even when they should pass or even worse may cause failing test cases to pass. | ||
# Excess of everything is bad. Isn’t it?< | # Excess of everything is bad. Isn’t it?<br>The over use of mock objects in a unit test may result in yielding little value to testing. If everything is mocked then there is a high chance that the application under test might not be adequately tested. | ||
# Poor use of Mock?< | # Poor use of Mock?<br>The close coupling of a mock object with a unit test might result in very high maintenance cost for the mock object itself when the requirement for application under test changes and subsequently test case changes. Ideally mock objects should be concerned with behavioral aspects of real objects and the coupling with test cases should be minimal if not none. | ||
=== A comparison of available Mock Object generation frameworks === | === A comparison of available Mock Object generation frameworks === | ||
Revision as of 02:36, 9 September 2009
Mock Objects are simulated objects in the object oriented environment to mimic the behavior of real objects in a controlled fashion. This comes in very handy when testing an application which interacts with a complex object. The controlled simulation facilitates the testing process which otherwise would be difficult of the behavior is unpredictable.
And why do we need it?
Mock Objects mimic the behavior of complex real objects in a controlled (user defined) way and thus are highly useful in unit testing when the real objects are impractical or impossible to be incorporated in the unit tests. If the real object has any of the following characteristic, it may be useful to use mock objects instead:
- Has non deterministic behavior (results, time taken to respond etc..)
- Has internal states that are difficult to reproduce
- Is slow as compared to rest of application under test (example Databases)
- Does not exists (e.g., interfacing module still in development or the object might change behavior)
- Collaborates with the application under test exclusively for the test-cases.
What’s the fuss about?
Wikipedia provides a good introduction to Mock Objects
"In object-oriented programming, mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A computer programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts."
This introduction summarizes the concept of mock objects in a non-technical but in a complete manner.
Under the hood.
The mock object is created to mimic the behavior of a real object. This is achieved by having the interface of the mock objects same as that of the real objects. This causes the application under the test to be ignorant of whether it is interfacing with a real object or a mock object.
Computer Scientists also draw a line of differentiation between mocks and fakes. If an object merely implements the interface and responds with predetermined responses it is considered as fake where as the mock objects which internally takes into the consideration the state of the object that is being mocked is termed as mock. Consider for example if we want to mock a file system. A fake would respond with standard responses, that means it is possible to read a file without opening it (remember the responses are standard), where as a real mock has to ensure that a file is opened first and then read method is invoked. This can be achieved by writing down some assertions in the mock objects.
Similar to assertions Mock objects can have expectations that are set by the unit test to facilitate simulation of a condition in the real objects. Consider testing a online credit card transaction software. The authorization usually is a third party process is mocked. In case the tester intends to test the transaction procedure when the card is not authorized then the mock object can have a field authorization expectation which can be set by the unit test as fail and pass accordingly testing the different scenarios.
There have to be some limitations.
- Who will guard the guard?
Mock Objects are used for unit-testing, but who will ensure that the mock object is correctly mimicking the behavior of a real object. Care needs to be taken while implementing mock objects, if the behavior is improperly implemented then it will cause the test cases to fail even when they should pass or even worse may cause failing test cases to pass. - Excess of everything is bad. Isn’t it?
The over use of mock objects in a unit test may result in yielding little value to testing. If everything is mocked then there is a high chance that the application under test might not be adequately tested. - Poor use of Mock?
The close coupling of a mock object with a unit test might result in very high maintenance cost for the mock object itself when the requirement for application under test changes and subsequently test case changes. Ideally mock objects should be concerned with behavioral aspects of real objects and the coupling with test cases should be minimal if not none.
A comparison of available Mock Object generation frameworks
The table below gives a general comparison of some of the available mock object generating frameworks.
| C | CMock is a ruby-based tool and it helps to automate creation of mock functions for unit testing in the C language. This tool requires Ruby's Make-like facility and generate C code automatically CMock. | ||
| C++ | mockpp parses the header file of C++ (, which is converted into XML format) and created various user defined C++ code to emulate some functionality of your existing code rely on. |
| |
| C++ | amop uses ABI and template techniques and then, simulate a pseudo-"Reflection". This one does not require the interfaces of the generated mock object.
|
||
| C++ | MockItNow captures function calls and reorder them to record and replay. | ||
| C++ | m0cxx0r records function calls and compares them to expectation. Then, the tool generates mock objects for C++. | ||
| C# | Attach dynamically generates stub objects with support of the the 3A pattern (arrange/act/assert). This tool does not require interfaces. | ||
| C# | Moq is requires setting up common expectations to a fixture setup method and generates .NET mock objects.
|
||
| C# | This tool is a dynamic mock object library for C#. |
| |
| C# | NMockLib is simulates entire apis of code and interfaces for C#. | ||
| Java | EasyMock records expected behavior on given test code and replay them at runtime. | ||
| Java | JMock requires definition of mock objects and generates mock object at runtime. | ||
| Java | MockMaker requires user defined interface definitions at compile-time (build time) | ||
| JavaScript | JSMock uses expectation recording and matching techniques. The tool generates stub on object method calls. | ||
| JavaScript | JSMockTool is a Javascript Mock Tool is Mock library using RSpec style. | ||
| JavaScript | Mock4JS is a dynamic-mock library for Javascript | ||
| Perl | Test::MockObject helps you to create mock objects that conform to given interfaces for Perl. | ||
| Perl | Test::Mock::Class creates mock classes based on Moose and Class::MOP for Perl. | ||
| Ruby | Mocha is a library to help generates mock and stub objects for Ruby using a similar syntax of JMock. | ||
| Ruby | is the original behavior driven development framework and generates mock objects for Ruby | ||
| Ruby | FlexMock uses RSpec behavior specification and generates mock objects for Ruby. |