Integration testing belongs to the middle layer of the testing pyramid, where the focus is on testing the parts of the system where components or adjacent systems communicate with each other. This communication can occur through various types of messaging services, protocols, data flows, etc., which constitute the integration between systems.
What is integration testing?
Integration testing is used to ensure the quality of integrations within a system and with adjacent systems. Integration testing is a form of Black Box testing, meaning the tester does not know the code that the system is built upon, and only the interfaces exposed by the system can be used for testing. The goal of integration testing is to verify that two systems or components within a system utilize each other’s interfaces correctly and can communicate effectively.
For example, an integration between two components within a system might involve one component responsible for a web interface to sell products and another service managing inventory data. In this scenario, integration testing would attempt to ensure that the first component sends correctly formulated queries to the inventory service and interprets the responses correctly—ensuring that the components can exchange information effectively.
Within the spectrum of integration testing, tests can range from those resembling system-level tests to those closer to unit tests. At a higher level in the testing pyramid, multiple components and systems can be interconnected to test many integrations together. In other situations, it might be more appropriate to test a single component in an isolated environment with simulated integrations from surrounding systems. Typically, a blend of these approaches works well, with the majority of testing focused closer to unit testing levels and additional testing targeting larger flows involving multiple integrations.
Simulation and automation
Simulation and automation can provide testers with more control because it’s easier to simulate abnormal behavior of an integrating component than to induce abnormal behavior in a component designed to function correctly. In other words, simulation opens up the possibility to conduct negative test cases and extensively quality-assure error handling.
Simulation and automation can also be beneficial in reducing testing dependencies on parts of the system or components being integrated. This means that testing within a development team doesn’t have to wait for another team to complete their part of a specific integration, as the behavior can instead be simulated in the test environment.
To enable simulation, test tools are required that can communicate with the services at the interface where the integration is implemented. These tools could be commercial software or something developed by the tester in a suitable programming language.
Many testing tools support the creation and use of test doubles (such as mocks, stubs, and spies). These can be employed in a test case to replace a component, method, or class with a fake double that exhibits specific desired behaviors (for example, always generating an error message) or has the ability to “remember” how it was used in the test case, ensuring correct usage verification.
API testing
In many applications, integration occurs via APIs (e.g. over HTTP), often with collaborators who are not known in advance. Increasingly, government agencies and organizations offer open APIs to publish their data, and closed products may also provide APIs to integrate with other products on the market. API testing aims to ensure that the system not only performs as promised by the API but also that the data exposed is actually useful for API users.
Testing is typically conducted using some form of tool, often automated. Depending on the testing objectives, it may involve testing individual API calls in isolation or longer sequences of calls that form part of a broader end-to-end test.
A specific technique within API testing is contract testing, where a machine-readable contract is established between the API provider and API consumer. This contract typically includes multiple examples of different calls with corresponding responses. The idea is that the provider, for instance during a new release, can verify that the API still behaves according to the contract. Consumers can also use the contract to ensure that their systems make calls according to the contract and interpret responses correctly based on the examples.
Kontakta oss för konsultation eller frågor rörande tillgänglighetstestning
Har du frågor eller behöver hjälp med implementeringen av det tillgänglighetstestning? Tveka inte att höra av dig till oss. Fyll i formuläret så återkommer vi till dig inom kort. Vi finns här för att hjälpa dig att ta nästa steg i din digitala utveckling.
