unit-testing - stub /模拟与服务虚拟化..？哎呀

Question

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

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

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

提前致谢!

编辑:

检查了下面发布的链接(1)之一后，我想这就是我所得到的:

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

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

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

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

Answer 1

很好的问题。基本上， stub 将测试套件与环境断开连接，服务虚拟化模拟环境以更好地实现测试的真实意图。

更详细...

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

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

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

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

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