In the world of software development, every moderately complex software application will have a large code base consisting of several modules. There will be several software developers working on a given module. if you are a software developer, how would you ensure that your changes have not broken some existing functionality? How would you know if some other developer has made some changes that will end up breaking your code changes? One way is to keep testing the application 24/7 and making sure you have covered every possible use case. This is not only a preposterous but also an impossible approach to solving the problem at hand. This is exactly where Integration tests come into play.
While developing the software application, we create integration tests for as many use cases as we can. At the very least, we need to ensure that we have tests for the core use cases, the bread and butter of the application. Once we have these tests in place, we run them before every new check-in that happens. If any of the existing tests fail, that will mean that the new changes need to reviewed before they can be checked-in. Every developer needs to make it a habit to run these tests before every check-in.
There should also be continuous integration builds in place for the integration tests project. This will ensure that the tests will get run on different environments along the deployment cycle. This will ensure that there are no environment-specific dependencies that will cause the test to pass in one environment and fail in another. This will ensure that the tests are self-contained and can be run in any environment that we need to. If the company plans to move towards a continuous delivery model, then it becomes even more imperative that the integration tests are run during every build cycle.
Besides the functionality-breaking reasons, there is one other very important reason to have integration tests. Since the integration tests are self-contained, they are repeatable, which means they can be run over and over without causing any side effects. This is something that is not possible functionally. Let us say you are trying to troubleshoot a particular issue that requires certain data to be present. If you wanted to point your code to the application itself, then you would have to recreate the scenario and associated data every single time.This could be a very tiresome and time-consuming process that can be very frustrating. This can be compounded several times if your servers are on different machines across different networks.
With integration tests, you can simulate the issue via code on your local machine. Since the test is repeatable, the required data will need to be created only once. The test can keep creating and dropping the scenario every time it is run. This will eliminate the need to crank up the application on the web server and go through the hassle of creating data inside the application. There is no dependency on external servers and associated latency. We are not impacted if the external servers are brought down for maintenance or if the databases are refreshed.
In the process of troubleshooting the issue via integration tests, we will end up writing more and more integration tests that will remain in place once we have managed to get them to pass. This repeatable nature of integration tests makes them very powerful and valuable.
