Testing / Mockito Interview Questions
Mockito is a JAVA-based library used for unit testing applications. This open-source library plays an important role in automated unit tests for the purpose of test-driven development or behavior-driven development. It uses a mock interface to add dummy functionality in the unit testing. It also uses Java reflection to create mock objects for an interface to test it.
Mockito is a mocking framework.
Mocking is the way to test the functionality of the class. The mock objects perform the mocking process of real service in isolation. These mock objects return the dummy data corresponding to the dummy input passed to the function.
The mocking process does not require you to connect to the database or file server to test functionality.
The Mock() method is used to create and inject the mocked instances. It gives you boilerplate assignments to work with these instances. The other way of creating the instances is using the @mock annotations.
There are many use cases of mocking needed to perform unit testing of the code under isolation and make the test highly repeatable and predictable.
Mocking is generally required when,
- Component shouldn't update the state in the system during unit testing. For example, saving data to the database will alter the state, so during unit testing, DB calls could be mocked in the component under test.
- When the implementation of certain API/libraries/dependency is unavailable, we can mock those to pretend that it is available. For instance, assume we are consuming a REST API that provides a list of stock. While the REST API implementation is in progress, we can simply mock the REST API so we get the list of sample stocks.
No, Use PowerMockito on top of Mockito to mock static methods.
No, not using mockito. However, using PowerMockit we can mock private methods.
Declare the methods as protected and mark them with the annotation @visibleForTesting
.
Mockito allows us to create mock objects and stub the behavior for our test cases. We usually mock the behavior using when() and thenReturn() on the mock object.
Assert works only if assertions (-ea) are enabled which is not required for Verify. Assert throws an exception and hence doesn't continue with the test if assert evaluates to false whereas it is not so with Verify.
No type safety: The parameter of doReturn is Object unlike thenReturn. So, there is no type checking in the compile time. When the type is mismatched in the runtime, there would be an WrongTypeOfReturnValue execption.
No side effect: The advantage of doReturn-when is no side effect. You can use doReturn-when to specify a return value on a spied object without making a side effect.
Mock libraries typically create mocks by dynamic instance creation at runtime, either through interfaces or through inheritance, and as the static method is not associated with any particular instance it is not possible for mocking frameworks (like Mockito, easy mock, etc) to mock Static methods.
Frameworks like PowerMock do have support for static methods that perform bytecode manipulation at runtime in order to mock static methods.
Mockito is a framework of choice for most of the java based projects. It is easy to implement, read and understand.
Limitations: static and private methods, constructors, final class cannot be mocked.
From Mockito 2 onwards, Interface default methods can be mocked.
- doReturn and thenReturn,
- doNothing ,
- doThrow and thenThrow.
Void methods can be used with Mockito's doNothing(), doThrow(), and doAnswer() methods.
doNothing().when(someObject).someMethod(anyObject());
Mockito.doThrow(new Exception()).when(instance).methodName();
Mockito.spy() spies on a real object and invokes the real method. This will allow us to call all the normal methods of the object while still tracking every interaction, just as we would with a mock.
Alternatively you may use @Spy Annotation.
Mockito ArgumentCaptor is utilized to capture arguments for mocked methods. ArgumentCaptor is utilized with Mockito verify() methods to get the arguments passed when any method is called. This way, we can provide supplemental JUnit assertions for our tests.
Both mock and spy can be used to mock methods or fields. The difference is that in mock, you are creating a complete mock or fake object while in spy, there is the real object and you just spying or stubbing specific methods of it.
- @Mock used to create and inject mocked instances.
- @Spy is used to create a real object and spy on the real object.
- @Captor is used to create an ArgumentCaptor.
- @InjectMocks is used to create an object of a class and insert its dependencies.
- @RunWith keeps the test clean and improves debugging. It additionally detects the unutilized stubs available in the test and initializes mocks annotated with @Mock annotation.
Hamcrest is a framework for writing matcher objects allowing 'match' rules to be defined declaratively. There are a number of situations where matchers are invaluable, such as UI validation or data filtering, but it is in the area of writing flexible tests that matchers are most commonly used.