Jump to content

Service virtualization

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Softwareqa (talk | contribs) at 17:39, 27 February 2014 (Undid revision 597081086 by 5.254.185.50 (talk) - Removing non-notable tools (not recognized in analyst reports or indisutry publications on service virtualization)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

In software engineering, a mock simulates the behavior of specific components. This is of use in heterogeneous component-based applications such as API-driven applications or service-oriented architectures. Software development and QA/testing is easier as an application under test (AUT) can be run even if dependent system components are unavailable or difficult-to-access. Some vendors call an aspect of mocking service virtualization.

Overview

Mocks simulate the behavior of software components to remove dependency constraints on development and testing teams. Such constraints occur in complex, interdependent environments when a component connected to the application under test is:

  • Not yet completed
  • Still evolving
  • Controlled by a third-party or partner
  • Available for testing only in limited capacity or at inconvenient times
  • Difficult to provision or configure in a test environment
  • Needed for simultaneous access by different teams with varied test data setup and other requirements
  • Restricted or costly to use for load and performance testing [1][2]

Mocking extends across all aspects of composite applications: services, databases, mainframes, ESBs, and other components that communicate using common messaging protocols.[3][4][5]

Mocks simulate only the behavior of the specific dependent components that developers or testers need to exercise in order to complete their end-to-end transactions, and therefor only simulate specific slices of dependent behavior critical to the execution of development and testing tasks. This provides just enough application logic so that the developers or testers get what they need without having to wait for the actual service to be completed and readily available. For instance, instead of virtualizing an entire database (and performing all associated test data management as well as setting up the database for every test session), you monitor how the application interacts with the database, then you simulate the related database behavior (the SQL queries that are passed to the database, the corresponding result sets that are returned, and so forth).[6] [7] [8]

How to mock services

Mocking a service involves creating and deploying a "virtual asset" that simulates the behavior of a real component which is required to exercise the application under test, but is difficult or impossible to access for development and testing purposes.

A virtual asset stands in for a dependent component by listening for requests and returning an appropriate response—with the appropriate performance. For a database, this might involve listening for a SQL statement, then returning data source rows. For a web service, this might involve listening for an XML message over HTTP, JMS, or MQ, then returning another XML message. The virtual asset's functionality and performance might reflect the actual functionality/performance of the dependent component, or it might simulate exceptional conditions (such as extreme loads or error conditions) to determine how the application under test responds under those circumstances.

Virtual assets are typically created by:

  • Recording live communication among components as the system is exercised from the application under test (AUT)
  • Providing logs representing historical communication among components
  • Analyzing service interface specifications (such as a WSDL)
  • Defining the behavior manually with various interface controls and data source values

They are then further configured to represent specific data, functionality, and response times.

Virtual assets are deployed locally or in the cloud (public or private). With development/test environments configured to use the virtual assets in place of dependent components, developers or testers can then exercise the application they are working on without having to wait for the dependent components to be completed or readily accessible.[1][2][3][4][7]

Industry analysts report that service virtualization is best suited for "IT shops with significant experience with 'skipping' integration testing due to 'dependent software', and with a reasonably sophisticated test harness.[9]

Tools Available In The Market

Open source tools:

Commercial tools:

See also

References

  1. ^ a b Service Virtualization 101, by John Michelsen, iTKO Chalk Talk, February 1, 2010
  2. ^ a b Service Virtualization for Modern Applications by Gaurish Hattangadi, Virtual Strategy Magazine, November 28, 2010
  3. ^ a b Managing Test Environments by Liz McMillan, Cloud Computing Journal, December 2011
  4. ^ a b Application Behavior Virtualization by Elizabeth White, Cloud Computing Journal, December 2011
  5. ^ Database Virtualization For Development and Test by Wayne Ariola, ST & QA Magazine, March 2012
  6. ^ An Intro to SOA and Virtualization by John Michelsen, WebServices.org, August 2007
  7. ^ a b The Next Generation of Test Environment Management by Wayne Ariola, Virtualization Journal, July 12, 2011
  8. ^ Service Virtualization, a critical tool for "Shift Left" testing by manoj, Testing Thoughts, May 15, 2011
  9. ^ Parasoft and "Service Virtualization" Testing: A Good Idea by Wayne Kernochan, Thoughts From a Software IT Analyst, February 22, 2013
  10. ^ betamax homepage
  11. ^ betamax source code
  12. ^ https://github.com/rest-driver/rest-driver/wiki rest-driver homepage
  13. ^ VCR docs
  14. ^ WireMock Homepage
Retrieved from "https://en.wikipedia.org/w/index.php?title=Service_virtualization&oldid=597399104"