使用服务虚拟化改善开发者协做

对于一个开发人员来讲，没有什么比不断地从头开始重建事物更使人沮丧的了。面向对象设计的一个核心原则是可以为每一项工做建立一个对象或一个可参考的点，因此你永远没必要重复本身。

尽管有这个核心原则，但当涉及到模拟时，开发人员常常发现本身在不断地重复一样的过程。

但为何呢？当开发人员在编写应用程序代码时，他们常常与相同的外部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，若是存在一个，他们能够当即得到它。若是没有，他们能够建立一个虚拟服务，团队能够重复使用，而且将来任何须要它的人均可以发现。这就解决了相关协做的难题。

那么如今该怎么办呢？

开始与你的虚拟基础设施进行协做，你能够经过开始下载来走出第一步——资产能够检查到源控制，推广到共享团队服务器，并上传到你团队的私人市场。祝你虚拟化愉快！