存根/模拟与服务虚拟化..？呸呸呸答案

【问题标题】：Stubs / Mocks vs. Service Virtualization..? Yikes存根/模拟与服务虚拟化..？呸呸呸
【发布时间】：2012-08-21 13:14:12
【问题描述】：

我目前正在研究难以触及的领域的单元测试（我知道这是一个非常高级的观点），我遇到了这个问题：存根/模拟还是服务虚拟化？

我正在阅读以寻求答案，但我能找到的唯一资源似乎来自 SV 供应商（他们显然有偏见）。

谁能想到一个绝对比另一个更合适的例子，为什么？如果答案是“视情况而定”，那么请提出原因/内容。似乎任何一种方式都可以实现相同的结果 - 这是时间（开发）或可用资金（GreenHat 等不便宜！）的问题。

提前致谢！

编辑：

检查了下面发布的链接之一 (1)，我认为这就是我要了解的内容：

“虚拟服务只是您可以自己制作的测试存根。

虽然您可以编写自己的存根代码，但一旦您克服了非常简单的行为，在整个软件开发生命周期中模拟您所依赖的所有系统的工作量和成本就会变得不堪重负。服务虚拟化要求自动化，因为模拟和建模可以通过软件的直接观察来进行，而不需要手动编码和调整。否则，您维护存根环境所花费的时间可能与构建和测试应用程序功能本身所花费的时间一样多。”

基本上和任何工具一样，嗯？

(1)http://servicevirtualization.com/top-10

【问题讨论】：

标签： unit-testing mocking stub service-virtualization

【解决方案1】：

很好的问题。基本上，存根将测试套件与环境断开连接，服务虚拟化模拟环境，以便更好地执行测试的真正意图。

更详细...

存根为对象、方法或函数提供替代实现，以消除外部依赖。存根通常在单元和组件测试期间用于两个主要目的： 1) 将被测代码与集成环境隔离 2) 当无法访问外部资源或有问题的方法/函数/对象时，使测试能够继续进行。

如果您尝试编写单元测试并需要替换对数据库、外部库（例如文件 I/O）或其他系统 API 的简单调用，那么存根可能非常适合您的需求。

虽然存根/模拟通常用于“跳过”不可用的系统组件，但服务虚拟化允许团队成员模拟环境（或特定组件）并将其行为提供给整个团队。例如，服务虚拟化可用于模拟正在发展、尚不可用或难以访问/配置的依赖组件（例如第 3 方服务、数据库、大型机、打包应用程序等）的行为测试。

服务虚拟化可以代表比简单的存根和模拟更现实的行为。如果您可以访问依赖的应用程序，您可以通过从实时系统记录来在“虚拟资产”中捕获其当前行为。或者，您可以对代表预期行为的虚拟资产进行建模。然后，您可以通过参数化其条件行为、性能标准和测试数据来配置此虚拟资产。此外，您可以轻松地修改虚拟资产以生成适当的故障条件、异常等分类，以验证整个系统行为。

我工作的公司 Parasoft 解决了这两个用例。我们的开发测试平台促进了单元测试的存根生成和管理，我们获得 Jolt 奖的 Parasoft Virtualize 产品提供服务虚拟化。有关详细信息，请参阅 http://www.parasoft.com/service-virtualization 和 http://www.parasoft.com/development-testing。

【讨论】：

感谢您的回复，我一定会看看的。您能否详细说明您的观点，即 SV 可以代表更现实的行为？你的意思是说它可以更容易代表它吗？从开发的角度来看，自动捕获元素听起来很棒，但可以肯定的是，存根的功能最终完全取决于编码它所花费的精力。此外，SV 软件通常使用什么平台/技术来传达其模拟功能，即代码库通过什么机制与 VS 连接？提前致谢！

【解决方案2】：

IMO，单元测试不应依赖于外部服务，包括 Service Virtualization。

在编写集成测试、功能测试、端到端测试时，您只需要将这些依赖关系连接到外部服务。

尽管所有这些类型都可以在 JUnit 等测试框架中编写或驱动，但它们是不同类型的测试。

【讨论】：

【解决方案3】：

这里是 InfoQ 的一篇文章，概述了这些差异：Stubbing, Mocking and Service Virtualization Differences for Test and Development Teams

来自文章：

存根：接口的最小实现，通常返回与测试套件紧密耦合的硬编码数据。当测试套件很简单并且将硬编码数据保留在存根中不是问题时，它最有用。有些存根是手写的；有些可以通过工具生成。存根通常由开发人员编写供个人使用。它可以与测试人员共享，但更广泛的共享通常受到与硬编码的软件平台和部署基础设施依赖关系相关的互操作性问题的限制。一种常见的做法是，当存根直接在进程中使用类、方法和函数进行单元、模块和验收测试时。一些开发人员会说存根也可以被启动，但您无法验证存根上的调用。存根也可以“通过网络”进行通信，例如 HTTP，但有些人认为在这种情况下它们应该被称为虚拟服务。

Mock：一个可编程的接口观察器，根据测试定义的期望来验证输出。它经常使用第三方库创建，例如在 Java 中的 Mockito、JMock 或 WireMock。当您有大量测试并且存根不够用时，它最有用，因为每个测试都需要设置不同的数据，并且在存根中维护它们的成本很高。模拟让我们在测试中保持数据设置。模拟通常由开发人员编写供个人使用，但可以与测试人员共享。然而，更广泛的共享通常受到与硬编码的软件平台和部署基础设施依赖相关的互操作性问题的限制。他们通常直接在进程内处理单元、模块和验收测试的类、方法和函数。 Mock 根据满足预定义条件的给定请求提供响应（也称为请求或参数匹配）。模拟还关注交互而不是状态，因此模拟通常是有状态的。例如，您可以验证给定方法被调用的次数或对给定对象的调用顺序。

虚拟服务：通常作为软件即服务 (SaaS) 提供的测试替身，始终被远程调用，并且永远不会直接使用方法或函数在进程中工作。虚拟服务通常是通过使用服务虚拟化平台之一记录流量来创建的，而不是基于接口或 API 文档从头开始构建交互模式。虚拟服务可用于为团队建立共同基础，以便与其他开发团队以及测试团队进行沟通和促进工件共享。远程调用虚拟服务（通过 HTTP、TCP 等）通常支持多种协议（例如 HTTP、MQ、TCP 等），而存根或模拟通常仅支持一种。有时，虚拟服务需要用户授权，尤其是在部署在具有企业范围可见性的环境中时。用于创建虚拟服务的服务虚拟化工具通常具有用户界面，允许不太懂技术的软件测试人员在深入了解特定协议如何工作的细节之前开始运行。它们有时由数据库支持。它们还可以模拟系统的非功能特性，例如响应时间或慢速连接。您有时可以找到为给定请求标准提供一组存根响应的虚拟服务，并将所有其他请求传递给实时后端系统（部分存根）。与模拟类似，虚拟服务可以有相当复杂的请求匹配器，允许为许多不同类型的请求返回一个响应。有时，虚拟服务通过根据请求属性和数据构造部分响应来模拟系统行为。

通常很难确定测试替身适合以下哪些类别。它们应该被视为光谱而不是严格的定义。

【讨论】：

虽然此链接可能会回答问题，但最好在此处包含答案的基本部分并提供链接以供参考。如果链接页面发生更改，仅链接答案可能会失效。 - From Review
当然，我已经内联了关键部分

【解决方案4】：

我们的意思是 SV 可以比存根更真实地表示行为。服务虚拟化不需要像孤岛一样运行；它们可以代表复合行为。例如，调用一个虚拟端点中的资金转移可以触发另一个虚拟端点的帐户余额更新。这允许虚拟资产以有状态的方式运行，并允许您轻松地对整个系统的行为进行建模——即使该行为跨越多个连接、协议或接口。

【讨论】：