Service virtualization

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.

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.

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.