During integration testing, the different modules or components of the application are combined and tested together. Integration tests are executed just after the unit tests, where each of the units or modules has been tested separately.
Reference: https://medium.com/@allenliuzihao/automated-integration-testing-a295d21e513a
Integration tests are difficult from the application point of view because the modules have different types of input and output. The output of one module is fed or integrated with another module, and here the problem starts.
With Agile and CI/CD, integration tests are required to be automated as well, to become a part of a continuous testing cycle. However, it is not a good idea to consider all the integration tests as candidates of automation.
It is advisable to automate the integration tests when:
Integration tests are run frequently
When we talk about regression tests, we know they are frequent during a development cycle. That is why they are the best candidates for automation testing. However, when we are trying to automate the integration tests, it is required to apply the same approach over here.
We cannot run the integration test scripts forever as shown below, obviously, we need to formulate an approach.
Example: Consider a banking application, where there are different modules such as login, making payment, account statement, deposits, etc.
Are they run frequently? Considering the difficulty integration tests already pose, writing the automation test scripts should not become an additional burden. The integration tests for this example application are run frequently, either in the day or during the nightly run.
There can be two types of integration tests:
Short-running tests: These integration tests take a shorter time span to execute.
E.g. Email the bank account statement. Here we are checking the integration between the database from where the bank statement is fetched and the external printer mailing software/app.
Long-running tests: These integration tests take a longer time span to execute.
E.g. Add a new beneficiary and then make payment. Here we are checking the integration of the database with the payment system of the banking application.
Unit tests are run as soon as a new build is pushed by developers. However, we can plan to run the short-running integration test scripts in the day and the long-running test in the nightly cycle.
Also, to reduce the testing period, short-running integration tests can be run more frequently and long-running tests may be run once in two days.
Therefore, while planning the automation the frequency of the integration tests should be considered. It is not wise to waste time and effort in writing automation test scripts for rarely run integration tests.
Application is fairly stable
During unit testing, the tests are confined to a small module/unit which has no outside interaction. It is quite easy to locate the problem area and to fix it because of this reason.
However, when we are performing integration testing the components interact with each other. They have outside interactions and controlling factors influencing the result or output.
When an application is in the early stages of development it can behave in absurd ways during integration. Every time an integration test is run it provides a different output.
In such cases, it is difficult to compare the actual result with the expected result, since the actual result is unstable.
If the integration tests of an unstable application are automated they are bound to fail every time they are run because the actual result is changing.
Please bear in mind that the test environment plays a very important role during integration testing. The test environment should simulate the production environment and, needless to say, should be stable.
Below approaches can be used for performing integration testing of a stable application manually or through automation testing:
Incremental approach: The components are incrementally added one after another and tested. The types are:
Top-down: The higher level modules are tested first and the lower ones are added as stubs to simulate their behavior.
Example: An online shopping application. Application’s ‘Login’ page is developed however the ‘Admin’ module is not ready where the user can add/modify information. In this case, a lower-level module of ‘Admin’ will be added as a dummy and the application will be tested.
Bottom-up: The lower-level modules are tested first and the higher ones are added as drivers to simulate their behavior.
Example: For the same application consider a case when the ‘Admin’ page is ready to test. However, the ‘Login’ page is still pending development, we will use a driver for the ‘Login’ page to simulate its operation.
Hybrid: Uses the hybrid of the top-down and bottom-up approaches.
Reference:https://d1jnx9ba8s6j9r.cloudfront.net/blog/wp-content/uploads/2019/05/Stubs-Drivers-768x344.png
Non-incremental approach: We do not follow an incremental approach to integration here, i.e. adding the components one by one. The components are added together in one go and the whole software is tested thereafter.
Big bang approach: This is a type of non-incremental integration testing approach. As the name suggests all components are integrated together at once, just like a big bang.
During testing, if any failure occurs then it is difficult to find out the root cause because all modules were integrated together.
Therefore, the usage of the big bang approach is practical for small projects only where on the occurrence of failure the root cause can be analyzed.
Automation and execution is faster and requires less effort than manual testing
Consider a scenario where you decided to use automation for integration tests. To manually execute the integration tests the team requires 40 person-hours per month, the project is estimated to run 3 months.
Therefore the total time elapsed in manually running the test cases is = 40*3= 120 person-hours. Now let's assume to write the automation scripts for these integration tests the team took 80 person-hours in the first month.
This is exactly double the manual effort for a month, and the testing has not happened yet. However, in the coming two months the integration test scripts are run automatically without any manual effort. So overall the team saved 120-80 = 40 person-hours.
Additionally, in the next testing cycles, these automated integration tests can be reused. Hence, this approach works wonders because the time and effort are less than the manual testing.
Imagine using a codeless and intelligent testing tool in this situation, the team will not even require 80 person-hours to code. There is a low or zero learning curve and the team can directly start creating the test scripts.
Moreover, the non-technical people from business, management, etc. can participate in test case creation and execution. Testsigma is an NLP and AI-based codeless testing tool which supports testing on the cloud over thousands of environments.
Tools for Integration Testing
- Testsigma
- Steam
- TESSY
- Rational Integration Tester
- Citrus
Conclusion
Integration testing is not easy, because it deals with multiple components at a time, each with its database, data types, environment, etc.
Integration of two completely different components to work as a combined unit is challenging. Automation of integration testing should ease our pain and should not increase it in any way.
Additionally, integration testing is crucial for the success of software because during unit testing we execute the tests in isolation.
We do not know how the components will behave together. Once we know they are working fine together after integration, we move towards system testing.
Oldest comments (0)