对于一个开发人员来说，没有什么比不断地从头开始重建事物更令人沮丧的了。面向对象设计的一个核心原则是能够为每一项工作创建一个对象或一个可参考的点，所以你永远不必重复自己。
尽管有这个核心原则，但当涉及到模拟时，开发人员经常发现自己在不断地重复同样的过程。
但为什么呢？当开发人员在编写应用程序代码时，他们经常与相同的外部API进行通信，并以不同的方式对同一服务进行相同的调用。传统的mock的问题在于，它们是在代码层面编写的，而且它们是专门为与正在开发的功能一起工作而设计的。因此，每次需要行使该功能时，都必须创建一个新的mock。
在使用传统的mock框架时，很难共享已经创建的mock，不仅因为可能不知道它们存在于代码库中的什么位置，而且也很难理解一个特定的mock是与哪个需求绑定的。因此，最终发生的情况是，个别团队成员经常创建与坐在他们旁边的人相同的mock。这简直是在浪费开发者的精力和时间。
我的mock在哪里？一旦开发人员创建了一个mock，协作也变得很有挑战性。因为没有一个神奇的仪表板存在，你可以在那里发布关于已经创建的模拟的通知，让团队了解情况。
我最近有一家医疗机构的客户，该机构将模拟作为一种常见的开发实践，他们有一个服务提供商总是离线，这使得它成为模拟的常见目标。因此，各个开发人员都在自己的代码库中为它做了一个模拟界面。它们都略有不同，但达到了同样的目的。当我与这些开发者沟通时，我发现大约有20个相同的mock存在。这甚至也让他们感到惊讶。当被问及重复工作的问题时，他们的回答，却是语气沉稳，并不完全出乎意料。“我们太忙了，没时间沟通。”
听起来很熟悉？（我希望我在这里有一个实际统计的数据能让你感觉好一些）
但模拟是必要的，正如任何开发人员或测试人员会解释的那样，因为你在进行开发时需要有能力将自己与其他世界脱钩。模拟是一种用可保护的环境来包围你的应用程序的方法——但这个解决方案有其固有的挑战，包括：
- 从头开始重建每一个mock是很乏味的，而且浪费时间
- 试图发现现有的模拟是困难的
- Mocks的存在是没有目的的——它们不与特定的API挂钩，也不能重复使用
- 大家虽然需要合作，但忙于沟通，无暇顾及
进入：服务虚拟化。通过这种测试实践，你可以简化模拟的过程，并创建一个可重用的虚拟服务库，共享核心功能。所以你可以停止反复创建虚拟服务。
使用服务虚拟化我们来看一个例子。比方说，有一个现有的服务，通过接收一个传入的账号，为这个人提供身份信息，并返回一个响应，同时需要开发一个新的虚拟服务，在这个服务中，根据账号，返回财务细节。
通过服务虚拟化，在创建新的虚拟服务时，可以利用原有服务的很多内容。唯一能将两个服务分开的是模式和数据。而随着企业建立越来越多的虚拟服务，他们可以重用的工件库也会变得更大。这就解决了最初不得不反复创建相同虚拟服务的挑战。
共享虚拟服务
与mock不同，虚拟服务具有高度的可共享性，内部模块也可以重复使用。虚拟服务或pva文件可以以XML的形式存储，并且可以很容易地检查到源码控制中。如果服务模拟特定API的特定功能，你可以在源码控制中搜索工件，或者更容易在共享虚拟化服务器上搜索。随着团队对服务虚拟化使用的增长，他们可以利用现有的服务器共享功能，直接将自己的桌面连接到服务器上搜索自己需要的工件，直接拉到自己的桌面上，并立即开始使用。这就解决了发现已经创建的虚拟服务并立即访问的难题。
捆绑虚拟服务
Parasoft Virtualize还提供了一个从常见的虚拟化用例建立的私有和公共构件市场。这使你可以快速启动并在整个组织中建立一个内部知识库，以简化未来虚拟服务的创建。当你开始利用虚拟服务时，你可以轻松地将该虚拟服务与其初始 API 命名惯例或通过描述或标记联系在一起。
然后，你的开发伙伴可以直接在 Web 浏览器中搜索为他们想要模拟的 API 所创建的任何虚拟资产，并准确地看到已创建的虚拟资产，并立即部署到他们的桌面：
这就解决了将虚拟服务与其特定的API和要求联系在一起的挑战。
与虚拟服务协作
最后，鉴于以上所有的解决方案，你的团队可以建立一个可持续的工作流程，让开发人员和测试人员在意识到需要模拟时有选择。他们不必花时间来回奔波，而是可以在Parasoft生态系统中查询适合他们特定需求的mock，如果存在一个，他们可以立即获得它。如果没有，他们可以创建一个虚拟服务，团队可以重复使用，并且未来任何需要它的人都可以发现。这就解决了相关协作的难题。
那么现在该怎么办呢？开始与你的虚拟基础设施进行协作，你可以通过开始下载来走出第一步——资产可以检查到源控制，推广到共享团队服务器，并上传到你团队的私人市场。祝你虚拟化愉快！