Integration Tests (with examples)

Previously, we briefly mentioned the possibility of writing more system integration tests since having User Interface (UI) testing is expensive (in terms of time). Therefore, we’ll be introducing system integration testing in this article.

UI tests are always fun to write since we get to automate steps that we used to test manually such as clicking on a button, scrolling down the page, and eyeballing of data to ensure that the displayed data is accurate. All we have to do is to schedule an automated test to run, wait for the report to be generated, and check if any of the test scenarios have failed.

With an increasing number of features in the application, more UI tests would be written. And here comes the nightmare — flaky tests, high maintenance of test scenarios, and longer running time are needed to complete the set of UI tests. When the nightmare happens, that’s when we start looking to solve problems from a different angle. What should we have done and not done? UI tests that handle different permutations of test data (e.g. different types of logins fetching different sets of data) — can all these be done in system integration tests instead?

Integration Testing is performed to verify that different modules can work properly together as per the required functionality. It can be either integration of API or UI tests, or even both.

To get started in writing integration tests, one will need to understand the application flows well. So let’s take a look at the following example about borrowing books from an online library! Do note that we’ll be looking from both the integration of API and UI tests perspective.

UI Test Scenario: Verify user account details when login is success

Integration of APIs will be:

UI Test Scenario: Verify user’s book loan details when login is success

Integration of APIs will be:

Now we’ll look at how we can write more integration tests of APIs and reduce UI tests. Assuming the online library system has the following requirements:

• Two types of membership: { basic, premium }
• Some books are only available for premium type

Here’s how it will be if we write more UI tests instead of more integration tests:

UI test scenario: Display books when login is success

Instead of duplicating the test scenarios (in the UI tests) for different membership types, we can make use of data-driven BDD! And most people have the mindset that just because they’ve covered the different scenarios in the UI tests, they only need to cover one for the integration test.

Integration of APIs will be:

The problem of using this approach is that when more types of membership are to be introduced in future, it will take longer time to complete running the UI tests. This is because UI testing involves detecting the DOM element first before any action is triggered.

Example:
If the user needs to scroll down the webpage before clicking on the Submit button, the step of scrolling down the page has to be defined. If we were to reduce the number of UI tests and increase the number of integration tests instead, we’ll only need to write one UI test to verify if data is displayed correctly for either of the membership types.

UI test scenario: Display books when login is success

As for the integration tests, we can have two sets of tests — one test per membership type — where each test verifies if the book details fetched are correct for each membership type.

Integration of APIs will be:

By having more integration tests will save some time when it comes to solving bugs related to data. However, please bear in mind that there would still be cases whereby we’ll need to do manual testing, for example, captcha in the form; some scenarios are just not technically feasible to automate or there is just too much effort to do so.

Hope you guys have a better understanding of how the integration tests work and how it can help in reducing the number of UI tests. Different project teams may have different testing strategies and hope that you can find the best strategy that works for your project!

Happy labour day! Stay safe and healthy (at home), everyone~ ❤️❤️❤️

- Merlin