Get test integrations under control
Team's test automation often fails when service dependencies are insufficiently managed in testing environments. This problem is exacerbated when organizations migrate to a microservices architecture, as this increases the number of services and therefore the number of integrations each service has. When not managed correctly, these integrations may lead to untestable architectures and halt the overall migration to microservices. Service virtualization is a common technique to help get integrations under control by creating test doubles in the form of stubs and mocks.
Experience with service virtualization
We have been working with test automation since 2006, and began adopting a microservices architecture approach in 2012: we have a long history with this domain. Initially, we started facing issues with testing services in isolation, for the purposes of continuous delivery, and developed a number of battle-tested approaches to solve this problem. Over the years, we have helped multi-billion dollar enterprises with technology departments consisting of thousands of developers and testers tackle this issue in a lean and agile way. We bring our expertise and blueprints to analyze application portfolios, choose early candidates for adoption and scale service virtualization techniques across the board.
Building blocks
Analyze service dependencies
We start by analyzing dependencies of the services under test, as not all dependencies need to be virtualized. In some cases, when dependencies are well-defined and do not handle sensitive data, it makes sense to use real service endpoints. This saves effort on implementing initial stubs and mocks, reduces costs on maintenance in the long run, streamlines continuous delivery pipeline and makes testing more similar to production conditions.
Implement service virtualization
Service virtualization comes in several slightly different flavors of stubs and mocks, and may be implemented on various levels, from unit testing to service-level functional and performance testing. The common method to implement service virtualization includes a tool that allows recording sessions with real dependencies, and then plays pre-recorded responses during testing time. The tools and techniques may differ in complexity, ranging from simple record-and-replay scenarios to complex programmable replays with changing input and output data, to creation of fully synthetic data and business logic inside test doubles.
Manage test data for dependencies
Similarly to test data management, service virtualization must be maintained after initial implementation. Old recorded sessions should be updated from time to time based on changing data, changing requirements and changing service contracts. When real production dependencies are used for recording, data should be refreshed, tokenized and obfuscated. Regardless of whether synthetic or production data is used, test data management for virtualized dependencies follows the same guiding principles and rules as test data management.
How it works
Technology stack
Engagement model
We prefer a hands-on approach in our engagements from day one. Many clients that we engage with have already implemented some level of test automation. In these cases, our architects and engineers engage with the most challenging applications and services. For these applications, we start by looking at existing test suites implementation, existing integrations and dependencies and data in test datasets.
After we understand the current situation in depth, we make point improvements to bring the most value with the least effort and in the shortest period of time. Once the bleeding has been stopped, we move to long-term improvements in process and tooling, adopt modern techniques across the board and educate client teams to spread the knowledge and know-how within their organization.
