Service virtualization emulates only the behavior of the specific dependent components that developers or testers need to exercise in order to complete their end-to-end transactions.
[8] An alternative approach to working around the test environment access constraints outlined in this article's introduction is for team members to develop method stubs or mock objects that substitute for dependent resources.
[11] The earliest implementations of service virtualization were designed to automate the process of developing simple stub-like emulations so that composite applications could be tested more efficiently.
[12] As enterprise systems continued to grow increasingly complex and distributed, software tool vendors shifted focus from stubbing to the more environment-focused service virtualization.
[10] The increasing popularity[13] of Agile software development and DevOps has created demand for a new set of tools to deliver service virtualization to communities that work in this way.
[14] Practices such as Continuous delivery and moving away from mainframe and monolith development to more distributed microservice-based architectures fit well with the capabilities of service virtualization.