Integration Testing

Integration testing (definition) is one of the phases of software testing, in which individual software modules are combined and tested in a group. In test automation, the Continuous Integration System is used. The principle of integration testing is as follows:

The continuous integration system monitors the version control system.

If you change the source code in the repository, the local storage is updated.

Perform the necessary checks and unit tests.

Source codes are compiled into ready-made executable modules.

The integration level tests are performed.

Generated test report.

System integration testing and its productivity

For example: to increase developer productivity one organization decided to ensure that each development group has its own integration testing environment and the ability to scale it up if you need to check more lines of code or speed up the development process. Environment as a Service (EaaS): EaaS tools accelerate the operation of an application instance using the company’s internal cloud. Only the set of virtual machines needed to service this development group and the last working copy of the user interface are used.

Service Virtualization: The services of other web services and mainframe groups are virtualized. Only those services that are evaluated by the number of transactions are virtualized, others are used “live”.

Environment planning: for clarity, a planning system based on the Release Management tool is used, which “knows” in which environment the work is performed for a given release. However, since there is no shortage of environments, the planned distribution of media at the group level is not performed.

As a result, each development team received a number of small, low-cost environments that rely heavily on service virtualization. They could test their components in a larger system, but they are isolated from other groups. These other groups may disrupt their work, or they may worry about not spoiling the components of other groups. However, the substantial use of virtualization means that the integration of services cannot be immediately resolved.

Integration testing tools

Continuous integration systems are used to automate integration testing. The principle of operation of such systems is as follows:

CIS monitors version control systems;

When changing source codes in the repository, the local storage is updated;

Necessary checks and unit tests are performed;

Source codes are compiled into ready-made executable modules;

Tests are performed at the integration level;

A test report is generated.

Thus, automatic integration tests are performed immediately after making changes, which allows detecting and eliminating errors in a short time.

Environment constraints: integration testing framework

To understand how to get a redundant and high-quality testing environment to speed up feedback, you need to understand what the limitations of the existing environment are. This knowledge will help to cope with problems.

High initial costs: to create a new test environment, you need to allocate servers, configure middleware and run applications. These tasks require considerable effort.

High maintenance cost: as the number of test environments grows, the complexity of configuration tasks, patching, etc. increases.

Inconsistent use: sometimes a group needs a lot of media, and sometimes just a few is enough.

Costly components: Testing some components of the application is expensive; this limits the possibility of frequent repetition of tests. The limiting factor is also the necessary third-party web services, paid for by the number of transactions, mainframe components and resources of software and hardware complexes.

Faulty components: when there are many components that often change, it is highly likely that a component will fail at any time.

Maintaining the environment is easier if it is constantly in operation. But, unfortunately, to save equipment costs, it is desirable to turn it off when it is not in use.

Methods to eliminate bottlenecks

There are three approaches that help solve the problems of the integration testing environment and increase its accessibility: environment usage planning, environment as a service, and service virtualization. Each approach solves different parts of the problem.

Environment planning: integration testing with example

The simplest strategy is to actively plan and manage your use of the environment. Usually the responsibility for this lies with the release manager. Integration environments are treated as valuable resources and are allocated for testing a release, depending on its priority and timing. Modern release management tools, such as IBM UrbanCode Release, are capable of providing a formal tracking of the environment, planning and conflict detection, but until now, spreadsheets are widely used for this purpose.

Final integration testing

Integration testing remains virtually unchanged, and this is the largest environment. Both web services and mainframe virtualization of services is used. For mainframe and piece-rate services, virtualization is sometimes used when testing with a large number of transactions. In other performance testing scenarios, both third-party web service providers install stubs that respond slowly to requests to test application behavior when third-party service providers experience problems. For the final integration test, an integration testing environment is used. Since it provides access to valuable resources, such as the real version of the piecework services and components of the mainframe, it is subject to management and planning. The system of planning the use of the environment is still used to highlight its upcoming releases.