"The significant problems that exist in the world today cannot be solved by the level of thinking that created them."
– Albert Einstein
This chapter distills the Mockito framework to its main core and provides technical examples. No previous knowledge of Mocking is necessary.
The following topics are covered in this chapter:
The Exploring Mockito section covers the unit test qualities and significance of Mockito in unit testing.
The Working with Mockito section explicates the Mockito framework and covers the following topics:
The Understanding the Mockito architecture section explains the internal architecture of Mockito.
Mockito is an open source mocking framework for Java. Mockito comes under the MIT license. The MIT license says that anybody can use the software free of charge and can use, copy, modify, merge, publish, distribute, and sell the software.
In Chapter 1, Exploring Test Doubles, we read about test doubles, spies, stubs, and mock objects. Test doubles replicate the external dependencies so that the code under test can interact with its external dependencies and allow you to isolate code from its dependencies to test them on a standalone basis. Mockito streamlines the creation and management of external dependencies and allows mock object creation, verification, stubbing, and spying on real objects. To learn more about Mockito, visit the following links:
Writing clean, readable, and maintainable unit test cases (JUnit, TestNG) is an art; just like writing clean code. A well-written unit test can prevent maintenance nightmare and acts as a form of system documentation, but if not used carefully, it may produce meaningless boilerplate test cases.
Unit tests should adhere to a number of principles for readability, flexibility, and maintainability. This section elucidates the principles that we'll follow throughout this journey. The following are the principles:
Mockito provides APIs to mock out the external dependencies and achieve the qualities mentioned here.
Automated tests are a safety net. They run and notify if the system is broken so that the offending code can be fixed very quickly. If a test suite runs for an hour, the purpose of quick feedback is compromised.
Consider a development environment where every line of code changes (commits to the source control, for example, Git, SVN, or Rational ClearCase), triggers an automated test suite, and takes hours to complete. A developer has to wait for an hour or more to verify a new change until the test run is complete. This blocks the progress of the development.
A test may take time to execute or fail needlessly when your code exhibits testing-unfriendly behaviors or interacts with testing-unfriendly external objects.
The following are examples of testing-unfriendly behaviors:
Do we really need a database connection or Internet connectivity to unit test a piece of code?
If the connection to a database is not possible or the stock price cannot be downloaded, the code cannot be tested and a few parts of the system remain untested. So, DB interaction or network connection is mandatory for unit testing some parts of the system. To unit test these parts, you need to isolate the testing of unfriendly objects, or technically, the external dependencies need to be mocked out (or faked).
Mockito plays a key role in mocking external dependencies. Mockito can be used to mock out a database connection or any external I/O behavior so that the actual logic can be unit tested and your code can interact with the mocked external objects.
Mocking provides the following benefits:
18.117.99.152