Patterns and anti-patterns CI / CD. Part 2

All with Friday, friends. Today we are sharing with you the translation of the second part of the article “Patterns and anti-patterns of CI / CD” , the first part of which can be found here . Recall, this series of publications is timed to the launch of a new stream on the course “DevOps practices and tools” .

1.3 Patterns and antipatterns in testing

1.3.1 Test Automation
')

• Pattern: Automate software validation and validation by including unit, component, capacity, functionality, and deployment testing.
• Anti-patterns: Manual testing of units, components, deployment, and so on.
• Unit- Test automation without dependencies.
• Component- Test automation with dependencies on other components, databases and file systems.
• Deployment - Automate tests to verify deployment and configuration success. This is sometimes called “smoke” testing.
• Functional- Automation of tests for checking software behavior from the user's point of view.
• Capacity - Automation of testing load and performance in conditions close to operational.

1.3.2 Insulation Test Data

• Pattern: Use transactions for tests that depend on databases (for example, component testing) and roll back transactions upon completion. Use a small subset of data to effectively test behavior.
• Anti-patterns: Use copy data with production for Commit Stage tests. Run tests on a shared database.

1.3.3 Parallel Tests

• Pattern: In parallel, run several tests on hardware instances to reduce the elapsed time.
• Anti-patterns: Running tests on a single machine or instance. Run dependent tests that cannot be run in parallel.

1.3.4 System Stab

• Pattern: Use stubs to simulate external systems for the sake of reducing deployment complexity.
• Anti-patterns: Manual installation and configuration of interdependent systems for Commit Stage assembly and deployment.

1.3.5 End-to-End Testing Considered Harmful

Continuous Delivery is a set of holistic principles and practices aimed at reducing time to market. It is based on fast and reliable feedback due to tests. Continuous Delivery requires any changes to the code, configuration, data, or infrastructure to undergo a set of automated and exploratory tests in the Pipeline Deployment to assess operational readiness. Therefore, if an organization wants to achieve shorter deadlines, the test run time should be low, and the test results should be unambiguous.

For example, consider the Payments Company service, in which payments at the end of the year are sent to the next Payments service.

The behavior of the Company's Payments service can be checked during build time by running the following types of automated tests:

• Unit Tests: A comparison of the goal and implementation when testing individual code modules.
• Acceptance tests: comparison of implementation and requirements when checking the functional part of the system.
• End-to-end tests: comparison of implementation and requirements when checking the functional part of the system, including orphan dependent services.

While unit and acceptance tests differ in purpose and volume, acceptance and end-to-end tests differ only in volume. Acceptance tests do not include orphan dependent services, therefore the acceptance test of the user's journey of the Company's Payments will use the Test System consisting of the code of the latest version of the Payments of the Company and the Staba Payments.

End-to-end tests include orphan dependent services, therefore the end-to-end test of the user's travels of the Company's Payments will use the Test System consisting of the most recent code of the Company's Payments and the working version of Payments.

If a testing strategy is to be compatible with Continuous Delivery, then it must have an appropriate ratio of modular, acceptance, and end-to-end tests, which balances the need for information and fast, unambiguous feedback. If testing does not bring new information, then the defects go unnoticed. But if testing takes too long, delivery will be slow, and loss of profits will increase.

The end of the second part.

By tradition, we are waiting for your comments and invite you to an open day . And the third part of the article will be published a little later. ;-)