单元测试用例生成器[关闭]答案

【问题标题】：Unit test case generator [closed]单元测试用例生成器[关闭]
【发布时间】：2008-12-10 18:24:40
【问题描述】：

有没有人尝试过任何用于 .Net 的单元测试生成器？

我认为虽然它不能替代编写功能的人编写的任何好的单元测试，但我认为它会带走一些工作并成为我们可以改进单元的起点测试。

谢谢。

【问题讨论】：

【解决方案1】：

单元测试生成是执行单元测试的错误方法。进行单元测试的正确方法是在编写功能代码之前创建测试用例，然后开发代码直到测试通过，这就是所谓的 TDD（测试驱动开发）。

单元测试生成是一个坏主意的关键原因之一是，如果您现有的代码中有任何错误，将针对这些错误生成测试，因此如果您将来修复它们，错误的测试将会失败当它实际上已经修复时，你会认为它已经坏了。

但由于编写了代码，现在它是桥下的水。并且可能有错误的单元测试总比没有单元测试要好。我一直更喜欢 NUnit，并且有一个兼容 NUnit 的测试生成器here（非常实惠）。

【讨论】：

是的，这是错误的 TDD 方式，但如果您使用的是遗留代码，这是一个很好的基础，不是吗？
@Webjedi。我不这么认为。手工编写测试将帮助您了解代码应该做什么。运行一个测试生成器——它会产生可读性有问题的代码——对此无济于事。
没错。工具如何知道您的应用程序的行为应该是什么？如果您没有测试，最好使用 WatiN 或 Selenium 等为 UI 编写功能测试
+1 当使用 TDD 时，你是对的，测试生成器是没有用的。然而，当一个人编写非常简单的类作为数据存储库时，没有方法，在某种程度上坚持外观和工厂设计模式，您可能会负担得起使用测试生成器。此外，你用这种反应点亮了我的灯笼，应该考虑另一种方法。感谢您的全面回答。

【解决方案2】：

你考虑过Pex吗？它来自微软研究院。

Pex 会自动生成一个小的具有高代码覆盖率的测试套件 .NET 程序。为此，Pex 进行系统的程序分析（使用动态符号执行，类似于路径有界模型检查）以确定测试参数化单元测试的输入。 Pex 通过以下方式学习程序行为监控执行跟踪。 Pex 使用产生新的约束求解器测试不同的输入程序行为。

【讨论】：

【解决方案3】：

几年前，我修改了 Haskell 的 QuickCheck 以允许 purely functional Test Driven Development 进行生成测试。我的解决方案是保存生成失败测试用例的 PRNG 种子，并使用相同的种子运行未来的测试。

我最近得到了一份 .NET 工作，Google 发现 MbUnit did have 在 2004 年支持生成测试。我还发现了更新的 Gallio，但我在使用它时遇到了一些麻烦，我不记得具体是什么了。

所以，TDD 和生成式测试并不是相互排斥的，Gallio 是我最近看到的唯一 .NET 选项，我不记得为什么我现在不使用它了。

【讨论】：

【解决方案4】：

我为 .Net 创建了一个单元测试生成器 ErrorUnit

使用生成器进行 TDD 开发当然是实用的；例如，在对单击按钮时发生的情况进行编码时，以 TDD 方式使用 ErrorUnit 的一种方法是：

1) 首先手动创建一个测试，确保有按键按下事件；然后按照纯 TDD 创建事件和测试。

2) 然后运行程序，通过按钮导航到屏幕，并在事件方法中设置断点，按下按钮

3) 当断点被命中时，您可以单击 ErrorUnit 的“添加单元测试”来生成一个单元测试，其中所有对象和当前数据库状态已经被模拟。（根据需要对不同的用例状态重复）

4) 然后，您将更改创建的单元测试以使 Assert 与您希望单击按钮按照 TDD 执行的操作的结果相匹配。

5) 然后编写 click 事件背后的代码，并运行由 ErrorUnit 生成的部分（用于 Arrange 和 Act）和部分自定义（用于 Assert）的测试。

这样您就可以节省大部分用于输入“安排”和“动作”的时间。

ErrorUnit 还与错误日志一起使用，通过在单元测试中序列化和模拟错误时的确切状态来重现其他环境中的错误；将 TDD 用于解决生产问题。

【讨论】：