单元测试用例生成器

Question

有人尝试过为.Net生成单元测试的生成器吗？

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

谢谢。

- Biswanath

---

这是一个非常有趣的问题。我偶尔会在小项目中使用测试生成器，你的问题与我刚刚想知道的相关。 - Will Marcouiller

Answer 1

生成单元测试是错误的执行单元测试的方式。正确的做法是在编写功能代码之前创建测试用例，然后开发代码, 直到测试验证通过，这被称为TDD（测试驱动开发）。

生成单元测试的一个主要原因是不好的想法是，如果现有代码中存在任何错误，则测试将针对这些错误生成，因此，如果您在未来修复这些错误，则不良测试将失败，您将认为某些内容已损坏，而实际上已经修复了。

但既然代码已经编写，那么就水落石出了。可能存在错误的单元测试总比没有单元测试要好。我一直更喜欢NUnit，并且有一个兼容NUnit的测试生成器这里（非常实用）。

- TravisO

---

是的，这种做法并不是TDD的正确方式，但如果你正在处理遗留代码，这样做还算是一个不错的基础吧？ - Webjedi

@Webjedi。我觉得不是这样的。手写测试有助于理解代码的预期功能。运行测试生成器 - 由其可能难以阅读的代码生成 - 对此没有帮助。 - tvanfosson

没错。一个工具怎么知道你的应用程序应该有什么行为呢？如果你没有测试，最好使用WatiN或Selenium编写UI的功能测试。 - bryanbcook

当使用TDD时，你是对的，测试生成器没有用处。然而，当你编写相当简单的数据储存类，没有方法，并且以某种方式遵循Façade和Factory设计模式时，你可以使用测试生成器。此外，你的回答让我茅塞顿开，我会考虑不同的方法。感谢你详尽的回答。 - Will Marcouiller

Answer 2

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

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

- Pascal Paradis

---

Pex值得一看。我发现它对于我们编写的越来越多的扩展方法非常有用，这些方法到目前为止都没有经过测试。 - Frep D-Oronge

Answer 3

多年前，我修改了Haskell的QuickCheck，以便使用生成测试进行纯函数式测试驱动开发。我的解决方案是保存生成失败测试用例的PRNG种子，并使用相同的种子运行未来的测试。

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

因此，TDD和生成测试并不互斥，Gallio是我见过的唯一的最新的.NET选项，我不记得为什么现在不使用它了。

- shapr

Answer 4

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

在TDD开发中使用生成器确实很实用；例如，在编写按钮点击事件时，使用ErrorUnit进行TDD开发的方法如下：

1）首先手动创建一个测试以确保有按钮按下事件；然后按照纯TDD的方式创建事件和测试。

2）然后运行程序，导航到带有按钮的屏幕，并在事件方法中设置断点，然后按下按钮。

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

4）然后，您将修改创建的单元测试，以使其具有与TDD所需的按钮点击结果相匹配的Assert。

5）然后编写单击事件的代码，并运行由ErrorUnit部分生成（用于安排和操作）和部分自定义（用于Assert）的测试。

这样，您就可以节省大部分时间，而不必花费时间输入安排和操作。

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

- johng