In our case we are heavily dependent upon recipe loading, map loading. How good it would be if in a test we could skip that and test only the required things.
No, it’s not making fun of someone else’s code. It’s creating a mock implementation of an object that can be used as a stand-in in testing.This mock object stands-in for an object that collaborates with the object you are testing. The mock replaces domain dependencies with a mock implementations that is only used in testing. For example you might set up a mock database or a mock connection. Even we can mock the broker . A mock object allows you to set expectations. You set up the values to be passed to and returned by the mock object. The mock object lets you verify that the expectations were met. The mock object can examine the parameters it was passed and verify that it received the expected values.
Why engage in Object Mocking? The real object has behaviour that is hard to cause or is non-deterministic. For example you need to make sure the object you are testing handles an exception thrown from a method invoked on another object. Sometimes it is impossible to force the exception to be thrown on the real object, but an exception can be easily thrown from a mock object. The real object is difficult to set up. Often you must manage the state of an object before using it in a test. This can be difficult if not impossible accomplish. Mock objects can make it much easier to setup state especially when testing objects that need to work with a database or network. The real object has (or is) a User Interface. Interaction with a GUI can be especially troublesome. Interacting with a mock object however can be much simpler. Test needs to query the object, but queries are not available. For example you need to determine if a “callback” method was invoked. Since the mock object verifies that each method was invoked as specified we can know that the “callback” was invoked. If you are engaging in Test-First development the real object may not exist. Using a mock object can aid in interface discovery, a mock object serves as a hypothesis of how an object should act.
We will have a look of only EasyMock. After the overview will see some examples using EasyMock.
EasyMock uses reflection to dynamically create proxies that implement the specified interface at run time. So the generation of the mock object becomes part of your unit test. EasyMock actually generates two objects at runtime, the Mock Object Mock Object which is an implementation of the interface to simulate and the Easy Mock Mock control which has methods for controlling its associated mock.
Easy mock allows you to specify the parameters that should be passed to a method when it is invoked on the mock object. Easy mock also allows you to specify the value to be returned from a method invocation. Easymock also allows you to specify the number of times a method should be invoked. You can also specify the number of times a method should expect a parameter or return a parameter. You can also specify that an exception should be thrown. So for example you could specify that the doit method should be called 2 times with the string ABC as a parameter and the string DEF the third time, it should return true the first two times and throw an exception the third. Finally you can use the verify method to make sure everything went as expected.
EasyMock generates it’s mocks at runtime so there is no way to modify the behavior other than through the provided methods. This is sufficient in most cases. Another problem may be that EasyMock uses an objects equals method to compare the expected parameter with the one that was passed from the test object. Sometimes, for example in comparing arrays this may not be what you want.
We can mock Interface, classes ( even abstract classes). But we cannot mock final classes.
I believe that the use of mock objects can really improved our testing capability.