API Virtualization and Mocking are NOT synonyms.
Many IT professionals confuse the two, failing to see the differences between them. But there are differences, and important differences at that.
API Virtualization, mocking (and stubbing) are all “test doubles” – techniques to allow integration testing by substituting a double for the real system with which integration is required (the “depended on component,” or DOC). The aim is to make the system under test (the SUT) “think” that it is dealing with the real DOC.
Stubbing uses very basic test doubles and is only useful for the most simple of integration tests. Typically data would be hard-coded in the stub and would be returned to the system under test under explicit instances. The simplicity of a stub means that often a developer can write his/her own stub, although tools do exist but are usually not cost effective for one-off situations. Passing a stubbed integration test provides little assurance that the integration has been properly designed and coded.
Mocking is more sophisticated than stubbing (and the two terms should not be used interchangeably: martinfowler.com Mocks Aren’t Stubs). Mocking tools are required to handle the sophistication. Data are not hard-coded. Instead, in mocking objects are pre-programmed so that they know how they should be called, and are hence able to report whether or not they have been called correctly. This “behavior verification” is the key distinguishing factor between mocks and stubs.
But mocking is not the holy grail of test doubles. The next level of sophistication (and the most sophisticated approach in widespread use) is API virtualization.
API Virtualization employs a tool that creates a virtualized copy of an API. This copy is complete (or at least partially complete overall but fully complete for the subset of API functionality that is required for the particular testing that is being performed). It means that you can mimic production wihout setting up a complete server stack. Hence you can save time, money and cost yet retain the full benefits of functional testing (non-functional is a different matter).
API virtualization is an improvement on mocking because it is not context restricted. Mocking encompasses just a subset of scenarios and mock objects are coded for these scenarios only. Theoretically API virtualization replicates completely the functionality of the API and hence is context unbound. Virtualized APIs need only be written once and then they remain for ever in the testing arsenal, with re-writes/updates only required if the specification of the original API is modified.