Integration testing helps developers identify bugs in the interfaces and in the interactions between integrated systems and components. Essentially, it is a test between the API provider and the API consumer that ensures the returned responses are as expected.
After completing integration testing, developers can identify any communication errors in the API process, as this testing looks at both the interfaces and the way the data flows between the different modules.
There are four primary types of integration testing:
Top Down, where testers begin with the higher-level components and progress to the lower-level ones. These tests are most beneficial in systems where some parts have more priority over other, lesser components.
Bottom Up, which you might have guessed is the opposite of Top Down, and begins with testing in the lower-level modules. This testing method is best deployed when there are only a few low-level systems. When components aren’t completely ready for testing, both Top Down and Bottom Up testing rely on stub and driver functions, which are dummy programs that act as the missing components for testing purposes.
Hybrid approaches, also called the Sandwich approach, combine Top Down tests with Bottom Up tests. This is especially suited for large software projects that contain multiple subsystems.
The fourth approach is the Big Bang technique, which tests the entire application after all components have been interlinked. This method is great when the entire system is put together but can make it difficult to isolate individual issues.
Getting Integration Testing Right
There are a few steps you should also follow when developing your integration testing approach.
First, determine which type of integration testing is right for your system. This is important, because making the wrong decision here could add development delays to your project and prove to be quite costly.
Once you’ve determined the right approach, you’ll want to create a testing plan. Your plan needs to be kept up to date, with fresh test designs that will protect your testing team from falling into a routine and performing ineffective tests that are misaligned with the project. Create planning documents, which will allow team members in multiple locations to easily navigate through the testing plan.
You’ll also need to be careful not to confuse integration tests with unit tests. Integration tests need to focus on the interaction between the modules, while unit tests look for problems with the code. Stay focused on the task at hand as you test the effectiveness of your API communications.
Consumer Driven Contracts vs. an End-to-End Approach
When testing APIs, the set of pre-defined requests and its expected response is called a contract. When performing an integration test, the test is ensuring that both sides of the API communication are speaking the same language and delivering on the contract.
There are several methods to achieve these results. Traditionally, developers have run end-to-end tests, while more recent testing methodologies have indicated that consumer-driven contract tests are a more effective approach.
End to End Approach
End-to-end (E2E) tests take place on real servers or containers, creating a situation where all API providers and API consumers are available in a production-like environment. These tests are executed when consumers are triggered through the user interface (UI). The consumer then calls the provider and the test shows, in the user interface, whether the results met the contract.
To put this in real world terms, if developers were testing a system where a user entered their birthdate and was presented with a list of historical events that happened on that date, entering the birthday through the UI would trigger a call from the API consumer to the API provider, which would be expected to return a list of events back to the UI. If it did so, the result of the test would be successful. In the event of failure, developers would then work to determine the cause of the failure, which might range from misconnections on the backend to date-format limitations on the UI side.
Consumer-Driven Contract Tests
In contrast to E2E tests, Consumer-Driven Contract (CDC) tests take place in a mock environment. Rather than running the full system on a production environment, these tests are isolated with the API consumer – rather than the API provider – driving the interaction. This is a big difference, and not intuitive, as it is the consumer that is driving the testing.
As mentioned above, CDC tests run in isolation, while E2E tests run in production environments. This presents a real advantage to the CDC tests. Tests run in isolated environments are easier to execute, and their results are more easily understood. When CDC tests fail, it’s clear where the point of failure is taking place and can be addressed by the developer.
E2E testing isn’t isolated, as each test may be calling on multiple different services. When results don’t match the contract, it may be difficult to determine the point of failure.
CDC tests are good at testing data syntax. For example, if you wanted to test a user entering a phone number in the system, a CDC test could easily check the format of the phone number. However, in an isolated environment, the test could not determine whether the phone number is actually valid.
E2E tests are stronger than CDC tests in this regard, as it’s playing with a full production environment. It can use the business logic built into the system to see if the phone number is valid.
For E2E testing to work, developers need to deploy containers running their services, live databases to draw on, and any other data dependencies that you have. CDC tests don’t require a complex environment, making it easier to run tests.
Time spent during testing limits productivity, meaning the faster your tests run, the more cost effective they are. E2E tests performed in full production environments take longer to return results. For starters, it takes much longer to set up the environment, but even once tests are running, the feedback cycle is extended. CDC tests, in contrast, have a shorter feedback cycle and significantly less set up time, allowing developers to get back to developing faster.
When running tests with commercial APIs, there may be operations that are built into the API which aren’t being used. As a result, there is extra code in the system which could put a drag on performance. CDC tests, which are consumer driven, can identify these unused APIs far more effectively than E2E tests, allowing developers to remove the unused code.
Moving Forward with Integration Testing
Integration testing is key to ensuring the effectiveness of communication between APIs. While planning your integration testing strategy, be sure to analyze your needs and follow a CDC approach for results that are easy to interpret.
Create Integration Tests with Seekret
Conventional testing only covers a small part of the picture and increasingly complex architectures always make creating and updating API tests far too expensive and simply not tenable. That’s why it’s so important to have a concrete integration testing strategy.
Seekret helps development teams optimize resources by automating the testing process for APIs and auto-generating API collections to save valuable developer time.
For more information on how Seekret can help you master your integration testing strategy, contact us today!