It happened again. A bug was accidentally released to the public in one of Anita’s apps. This rarely happened when she wrote the code on her own. Now with so many developers merging in code and fixing conflicts all while reviewing different PRs, it seems to be inevitable.
Using automation to control the frequency and location of tests can minimize this issue. This automation of testing is called Continuous Testing. It involves automatically triggering tests to be executed once an application is built in a new environment. Using continuous testing casts a wide net, catching bugs early and ensuring that the requirements of the project are met.
Tests can take a variety of forms with the most common being:
- Tests during development
- Unit Tests
- Integration Tests
- Tests before deployment to production
- Acceptance Tests
- End-to-end Tests
Since tests are triggered automatically each time the application is built in a new environment, developers don’t need to constantly monitor the state of the tests. Developers are simply notified of any failed tests by the automation tool, allowing them to quickly address the problem. When tests pass in a given environment, the approved code can automatically be moved into the next environment where even more tests may be executed.
Continuous testing is present in each part of the CI/CD pipeline. Since we are still new to the various components of this pipeline it’s okay if it’s not clear how these tests fit into the process. Over the next few exercises, we’ll return to continuous testing as we learn about each part of the pipeline, starting with Continuous Integration.