Automating Unit, Integration, and Functional Tests in CI/CD Pipelines

The primary goal of unit, integration, and functional testing is to increase confidence in each new version released. In theory, extensive testing ensures that every new feature released does not introduce regressions.

To achieve this goal, tests should be fully automated and managed by a CI/CD platform. Tests should run not only before each deployment but also after a pull request is created. The only way to achieve this level of automation is to make the test suite runnable in a single step.

Unfortunately, many companies still create tests in a relatively old-fashioned way, where a large group of test engineers manually execute various test suites. This blocks all new releases because the testing speed essentially becomes the deployment speed.

Test engineers should only write new tests. They should never manually execute tests themselves, as this greatly lengthens the feedback loop for new features. Tests are always automatically executed by the CI/CD platform across various workflows and pipelines.

If people manually run a small number of tests as a smoke test for a release, that is acceptable, but it should only happen for a few tests. All other major test suites should be fully automated.