Pex 用户：您对 Pex 和自动探索性测试的总体印象如何？答案

【问题标题】：Pex users: what are your Impressions of Pex and Automated Exploratory Testing in general?Pex 用户：您对 Pex 和自动探索性测试的总体印象如何？
【发布时间】：2010-09-08 17:35:38
【问题描述】：

用过Pex的小伙伴们，你觉得Pex这个工具的优缺点是什么？

另外，您认为“自动化探索性测试”总体上的优缺点是什么，作为对 TDD/单元测试的补充？

【问题讨论】：

探索性测试在 QA 中有何意义？就 ISTQB/ISEB/IEEE/ISO 而言，它看起来与探索性测试相去甚远。它不是一个分析你的代码并根据它在其中实现的规则生成测试用例的工具吗？听起来更像是专家系统而不是探索性测试 - en.wikipedia.org/wiki/Exploratory_testing。
@yoosiba “自动探索性测试”是直接来自 MS (channel9.msdn.com/posts/briankel/…) 的用语。从那时起，他们似乎已经放弃了这个术语。

标签： unit-testing testing automated-tests pex

【解决方案1】：

我认为 Pex 作为一种探索性测试工具非常有趣。在这方面，我认为它是我想交给 QA 使用的东西。

作为 TDD 工具，它需要一些工作，因为 TDD 是一项设计活动。但是，我确实喜欢 Peli 前进的方向。对于自动化辅助设计，有话要说。例如，仅仅因为 TDD 是一种设计工具，我就没有理由不能在我设计时让一个自动化工具指出潜在的边缘情况，对吧？从一开始就建立质量。

查看这篇文章，其中 Peli 在 TDD 风格的工作流程中使用 Pex。 http://blog.dotnetwiki.org/TDDingABinaryHeapWithPexPart1.aspx

【讨论】：

tdd 真的是一种设计活动吗？我不认为我见过有人让 TDD 为他们做出任何设计决策。他们独立设计并使用 TDD 开发代码。
我正在努力提高我的 TDD 并发现 TDD 确实是一项设计活动，比实际代码本身更能引领设计

【解决方案2】：

Pex 让您编写参数化 单元测试。从这个意义上说，它完全符合 TDD/单元测试流程：编写测试，让 Pex “探索”它，找到一些失败的测试，修复代码等等。

最大的优势是您可以针对输入的类表达您的测试，而不仅仅是几个硬编码的值。这为编写测试提供了更多的表现力，也迫使您考虑代码应该满足的不变量/期望（即更难编写断言）。

【讨论】：

编辑了描述以指出可能的重叠，我想获得关于他们使用 Pex 的 TDDer 单元测试中有多少能够参数化的反馈。另外，我想知道缺点和优点。

【解决方案3】：

我真的很喜欢 Pex。它将为您从未想过的边缘案例提供测试，尤其是在您的团队很小并且编写方法的人和编写测试的人相同的情况下。

它还将提供您的方法将遵守的合同义务。

【讨论】：

【解决方案4】：

如果您查找有关编写理论的文献（谷歌 David Saff）——这是一种更通用的编写单元测试的方式，并使用 Pex 作为理论探索者，我发现从我迄今为止的经验来看，生产力发生了巨大的变化。我刚刚写了一篇博文，详细介绍了我在 TDD 中使用 Pex 的经历：http://taumuon-jabuka.blogspot.com/2009/01/theory-driven-development-using_11.html

正如我所说的 - 我将其视为类固醇的 TDD！它绝不会取代 TDD，而是增强活动。

【讨论】：

这是我目前的感受，但我试图弄清楚为什么 Pex 似乎并不庞大

【解决方案5】：

测试优先的开发使您可以构建代码以实现可测试性。在这方面，Pex 会在您的代码中找到巧妙而笨拙的路径，帮助超越简单的覆盖率指标。

Pex with Moles 的主要优点是在进行 Brownfield 开发时能够跟踪副作用：运行 Pex 一次并保存输出，然后应用代码更改，然后再次运行 Pex 以查看损坏的地方。

【讨论】：