What is Continuous Integration (CI)?
Continuous Integration refers to a software integration practice that involves regular integration of code changes to a shared code repository. Generally, integration occurs several times a day. It basically means that you commit small code changes frequently rather than infrequent big changes. Every commit triggers a build, which runs a number of tests that identify if already existing features have been disrupted by new changes.
Advantages of Continuous Integration (CI)
- Faster feedback: Since every code change triggers a series of tests, developers get immediate feedback on whether the code commit has disrupted the existing code.
- Increased transparency: With tests being triggered automatically, the entire team would know if a bug pops up. This makes it easier to raise issues.
- Easier integration: When code changes are being committed constantly, there is no point at which a major issue can go unnoticed. This means QAs fix minor bugs on an ongoing basis rather than deal with a cluster of code failures at once.
How to optimize tests for Continuous Integration (CI)
- Create smaller tests
Smaller test suites run faster. Reorganize all necessary tests into smaller suites. Perform the most important operation first.
For example, if a notepad-style app is being tested, then the first test should be automating the following functions: create notes, add text, save, close app, reopen and verify that the right text has been saved. If any of these functions fail, then there is a fundamental flaw that needs to be solved first.
- Restructure the test setup
Tests begin with a setup phase, and then perform the steps for verification. In the notepad app example, the test checks if the app is saving a certain text after it has been reopened. To do this, the test has to be set up with the text first.
This setup phase can be restructured for CI. For example, let’s say a team is running a suite of UI-driven tests that are time-consuming and lead to false failures because of timing and minor UI changes. If the test setup is restructured to be performed via API commands and the verification is done through the UI, it will have the same functional coverage but will be executed faster. The rate of false failures due to UI changes will also be reduced.
- Keep an eye on wait times
Sometimes, a test keeps failing because back-end elements did not respond in time or because a resource (possibly some external dependency) is still loading. A sleep statement can be put in as a temporary fix.
This works for a while, but if these statements are left in, they cause unnecessary delays. Replace them with wait statements that complete when a predetermined event occurs, instead of ending after a fixed period of time.
- Initiate tests automatically
In a non-CI environment, test suites are normally executed manually. Modify these scripts so as to include them in the CI pipeline. This means setting them up to run automatically whenever a change occurs to the code repository. Automate the tests that find problems which are usually difficult to fix. By identifying the problems sooner, the team will have more time to fix it.
- Use parallel testing
Parallel testing enables running multiple tests simultaneously on multiple devices and browsers. This is an optimal way to speed up tests and create an effective CI pipeline.
Say, a vital test suite contains five hundred test cases. This would take several hours to run in a linear fashion. However, if it is broken down into a dozen different suites that can run in parallel, the time taken is much lower. Consequently, the tests can be run more frequently, which results in better testing of code quality.
Optimizing tests for a CI pipeline significantly improves the testing process. But remember that this cannot be done without the right tools. Automated testing, in general, required a robust framework that is, ideally, connected to a vast range of real browsers and devices.
