Pex用户：你对Pex和自动化探索性测试有什么印象？

Question

如果你曾经使用过Pex，你认为它作为一种工具的优缺点是什么？

此外，您认为“自动探索测试”作为TDD/单元测试的补充，一般而言有哪些优缺点？

- Troy DeMonbreun

---

测试质量保证中的探索性测试是什么意思？看起来与ISTQB/ISEB/IEEE/ISO关于探索性测试相去甚远。它不是一个分析您的代码并基于其实施的规则生成测试用例的工具吗？听起来更像专家系统而不是探索性测试 - http://en.wikipedia.org/wiki/Exploratory_testing。 - yoosiba

@yoosiba “自动化探索性测试”是源自于微软(http://channel9.msdn.com/posts/briankel/Pex-Automated-Exploratory-Testing-for-NET/)的术语。看起来他们从那时起已经放弃了这个术语。 - Troy DeMonbreun

Answer 1

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

最大的优势是你可以表达你对于“输入类”而不仅是一些硬编码的值的测试。这给了你更多写测试的表达性，并迫使你考虑你的代码应该满足的不变量/期望（即更难编写断言）。

- Peli

---

编辑了描述以指出可能的重叠部分，我想知道使用Pex进行TDD的人能够参数化多少他们的单元测试。此外，我也想知道它的缺点和优点。 - Troy DeMonbreun

Answer 2

我觉得作为一款探索性测试工具，Pex实在很有吸引力。在这方面，我认为它是我想要移交给QA使用的东西。

作为TDD工具，它还需要改进，因为TDD是一项设计活动。然而，我喜欢Peli所指向的方向。自动辅助设计有其可取之处。例如，尽管TDD是一种设计工具，但我没理由不能在设计时让自动化工具指出潜在的边缘情况，对吧？从一开始就建立质量。

点开这篇文章，Peli在其中展示了如何以TDD风格的工作流程使用Pex。 http://blog.dotnetwiki.org/TDDingABinaryHeapWithPexPart1.aspx

- Haacked

---

TDD真的是一项设计活动吗？我认为我从未见过有人让TDD为他们做出任何设计决策。他们独立进行设计并使用TDD来开发代码。 - John Nicholas

我正在努力提高我的TDD水平，并发现TDD确实是一项设计活动，它主导着设计，而不是实际的代码本身。 - Calanus

Answer 3

如果你想了解有关写作理论（请搜索David Saff）的文献-这是一种更一般的编写单元测试的方式，并使用Pex作为理论探索器，从我的经验中发现生产力有了飞跃。我刚刚写了一篇博客文章详细介绍了我在TDD中使用Pex的经验，链接如下：http://taumuon-jabuka.blogspot.com/2009/01/theory-driven-development-using_11.html 正如我所说-我认为这是强化版的TDD！它绝不会取代TDD，但会增强活动。

- Gary Evans

---

这是我目前对此的感觉，但我正在努力弄清楚为什么Pex似乎不是那么重要。 - roundcrisis

Answer 4

我非常兴奋地看到了 Pex。它可以为你提供测试，包括你从未想过的边缘情况，尤其是在团队很小、编写方法和编写测试的人是同一人的情况下。

此外，它还可以提供您的方法将遵守的合同义务。

- Jon Dewees

Answer 5

测试驱动开发使您为可测试性构建代码结构。在这方面，Pex通过您的代码找到了聪明和笨拙的路径，并帮助您超越了简单的覆盖度指标。

Pex与Moles的主要优势是在进行现有项目开发时能够跟踪副作用：运行Pex一次并保存输出，然后应用代码更改并再次运行Pex以查看哪些内容出了问题。

- GregC