Mocking the objects
During writing software we always try to limit the dependencies. Therefore in order to form a greater whole our components must be coupled each other. These couplings create dependencies within the application. Application can be also dependent on some external resources like database, web service, file system or other resources.
During writing unit test for a method developers face challenges when writing unit tests how to handle those external dependencies. For example in order to run a test one may need to connect with database or some remote server or instantiate a complex class that created by someone else. All these dependencies hinder the ability to write unit tests. When such dependencies need a complex setup for the automated test to run, the end result is fragile tests that break, even if the code under test works perfectly.
Mock objects are designed to stand in for these components of the application and external resources. This allows testing code without consequences of interacting with other resources.
Why Mocking Is Important
When we write unit tests for a method we generally write test to code of that method. We try to isolate the code under test. After isolation we normally validate our code for a given condition. Generally condition is defined for input data. It also defined for the context and environment where the code will execute. So we can easily care about only the method at that point.
By to isolating the code, we can ensure that any failure of a test exactly points to the problem area of a specific method under test.
Developers should be able to run unit tests quickly. A small application can have hundreds of unit tests. During development we have to ensure that we can run all our tests most frequently so that we can ensure that any changes inside our methods and classes are working fine. We also have to ensure that those changes don’t make any negative impacts in other parts of the system. Even the code volume between passed test and failed test is too small then also has to examine what went wrong. If these tests take several hours or even just few minutes then we will consider that the tests doesn’t run frequently enough.
A test that doesn’t run frequently is worthless. Most tests take a long time to run because they are interacting with an external resource, such as a database. Database calls can be slow, especially if you are executing hundreds at once against a development database. An object that mocks that database can return predefined values for predefined parameters instantly without having to connect to a database and execute a SQL query. This provides much faster execution than querying the database directly.
Unit tests should be predictable and consistent. When writing a method and its corresponding tests then we should be able to be certain in some point like if the method receives X and Y as arguments then it will always return Z. Generally external resources and the data change over time. If method and the tests that invoke the method are rely on an external resource then we can’t guarantee that we will always get the same results for the same input parameters. By mocking this resource, we can be sure that you’re always getting consistent and reliable data to test your method against.
Most development projects are undertaken by teams of more than one person. In that case, unit tests should be able to run without impacting the test results of other teammates. If our test suite contains tests that change the state of a database table and other tests that rely on the data in that table then there are chance that two or more developers run the tests concurrently, they will all have failing tests. They are stepping on each other’s data, and none are getting the data they are expecting. Mocking these external resources ensures that won’t cause the tests run by other developers to fail based on incorrect or unexpected data.