by: Shamim Ahmed
In my prior blog, Continuous Test Data Management for Microservices, Part 1, we offered an introduction to the key approaches for applying continuous test data management (TDM) to microservices.
The continuous TDM process for microservices applications is similar to that for general continuous TDM (see figure below), but tailored to the nuances of the architecture. In this post, I’ll outline the key steps for applying TDM across the lifecycle.
Rigorous change impact analysis during this step is key to reducing the testing (and the TDM) burden for microservices applications—especially in the upper layers of the test pyramid and the CD stages of the lifecycle. There are various ways to do this, following are a few highlights:
We recommend a combination of both approaches to ensure sufficient test coverage, while minimizing the number of tests in a microservices context. Based on the change impact set, we prepare test data for the tests discussed above.
As discussed in the previous section, as part of development, a component developer must also define and implement these APIs:
Developers should use the white-box change impact testing technique discussed above to focus their unit and component testing efforts.
This is an important stage in which testers and test data engineers design, or potentially generate or refresh, the test data for test scenarios that have been affected by changes and that will be run in subsequent stages of the CI/CD lifecycle. This assessment is based on the backlog items under development. Testers use the TDM approaches described above for cross-service system testing and end-to-end testing.
In addition, the test data will need to be packaged, for example, in containers or using virtual data copies. This approach can ease and speed provisioning into the appropriate test environment, along with test scripts and other artifacts.
In this step, we typically run automated build verification tests and component regression tests using the test data generated in the previous step.
The focus in these stages is to run tests in the upper layers of the test pyramid using test data created during step 2(b). See figure below. The key in these stages is to minimize the elapsed time TDM activities require. This is an important consideration: The time required to create, provision, or deploy test data must not exceed the time it takes to deploy the application in each stage.
Continuous TDM is meant to be practiced in conjunction with continuous testing. Various resources offer insights into evolving to continuous testing. If you are already practicing continuous testing with microservices, and want to move to continuous TDM, our recommendation is to proceed as follows:
This two-part blog series has provided an overall approach for continuous TDM practices for microservices. As you can probably tell, such component-based applications are extremely well suited to supporting continuous TDM. This is true because these applications are modular and componentized.
Stay well, my friends, and may all your microservices TDM efforts be continuous!