Understanding continuous testing

Continuous testing automates as much of the testing as possible, running the tests frequently (before and after each build) as part of a CD pipeline.

This approach has the following benefits:

• Developers and the rest of the team get quick feedback on how the software is functioning and can immediately fix any issues.
• Tests’ reliability is better than that of manual tests, which are repetitive and error-prone.
• Software can be released more frequently because the feedback loop is shorter.

Using continuous, automated testing doesn’t mean you won’t also run some manual tests, such as exploratory or usability testing, throughout the delivery process.

Now, let’s look at the types of testing that are typically included in continuous testing.

Test types

The following are some test types typically used in continuous testing:

• Unit tests: These tests are building blocks, focusing on individual code units (functions, classes). Unit tests run quickly and provide fine-grained feedback.
• Integration tests: These tests verify how different parts of a system work together. Integration tests are crucial for identifying issues in the interactions between integrated components or systems. These are more likely to be run within your CI server where multiple code packages come together.
• Acceptance tests: These tests simulate real-world usage of a running application or service, verifying that essential functionality aligns with user expectations and business requirements. These may happen from your CI environment or other outside services that test applications running in a staging environment.

And now, let’s see how to make continuous testing happen.

Implementing continuous testing

The following is a list of fundamental principles and practices for teams to implement continuous testing:

• Test automation: Automating unit tests, integration tests, and regression tests is essential for continuous testing. Automation allows the team to quickly identify and address issues, making the testing process more efficient.
• Developer involvement in testing: Developers should be the people primarily responsible for creating and maintaining automated test suites.

  This approach ensures that tests are always updated based on code changes and that developers write code that is relatively easy to test. The natural consequence and best realization of this approach is the test-driven development (TDD) practice, which is described next.

• TDD: A software development methodology in which tests are written before code. Initially, the developer writes an automated test for a new function or feature and then writes the actual code. This test defines how the new functionality should behave.

  The developer then writes the minimal amount of code necessary to make the test pass. After the test passes, the developer then refactors the code, which involves cleaning up and optimizing the code without changing its functionality.

• Unit and acceptance tests’ proportion: One of the main goals of continuous testing is to detect and fix issues as soon as possible. Unit tests are typically faster than acceptance tests and are executed in the early phases, so the more issues are detected in unit tests, the sooner defects are detected and remediated.

  As much as possible, unit tests should do the work of detecting issues. When an error is found in acceptance tests or other manual tests, create an automated unit test for that behavior to ensure that this error is detected sooner if it occurs again.

Now that we’ve covered the main elements of continuous testing, we’ll explore automated deployment in the next section.