2011-07-23 23 views
5

为了减少代码重复,我希望以各种来源的编程方式生成单元测试。我能想到的一个简单方法是从一个方法中生成一大堆委托,该方法解析一些配置信息,并用[TestMethod]属性标记所有这些委托,然后由Visual Studio测试框架运行该属性。将C#代表转换为单元测试

我的动机是尽可能多地使用视觉工作室的测试报告功能,因为我可以使用一些C#的反射功能编写我自己的测试报告层,但我宁愿不用。我的解决方案看起来非常优雅和简单,但是我无法获得visual studio的测试框架来了解我正在尝试做什么,是否有人知道如何去做我想做的事?

+0

我认为这是保持相关的文件的测试是在单元测试中的所有数据的最佳实践定义在 - 你是否担心这可能会掩盖测试的目的? –

+0

配置信息将紧挨着测试,所以它不会很难遵循测试的结果。 – davidk01

+0

那么也许可以使用[TestCase](http://www.nunit.org/index.php?p=testCase&r=2.5.9)属性来实现呢? –

回答

1

您可能需要考虑来自Microsoft Research的Pex(可能还有Moles)。 Pex是一个自动生成高代码覆盖率的单元测试的研究项目,据称可以为测试选择有趣的输入和输出。我想这里有一些情报。 :)

我还没有亲自使用它,但我从一些同行听说Pex和痣是非常有趣的,并已帮助他们。可能值得一看。

希望这会有所帮助!

1

我想如果你真的想生成测试,那么最好使用类似于T4 templates的东西来生成测试。换句话说,使用代码生成并创建测试装置和方法,以便像任何其他测试用例那样运行它们。

0

对不起,如果这不能正确回答您的问题,但我认为自动生成单元测试是解决此问题的错误方法。
单元测试是一种有效的方法,可帮助避免回归并提供文档来了解如何使用代码。当你自动生成你的测试时,你会得到一堆测试,但是如果它们失败了,你不会真正知道是否存在一个真正的错误,并且最终会有很多失败的测试,你不知道它们为什么会失败或者如何使它们失败通过。最后你可能会删除所有的测试 - 因为它们“不起作用”。

话虽如此 - 从Typemock尝试Armadillo - 这是一个工具,根据用户的操作写入测试

+0

大家一直在提出这一点,但它没有任何意义。整个测试的目的是清除错误,并提供文档,并从配置文件生成测试,清楚地显示输入和输出应该是一样好。当ORM映射器被用于自动生成脚手架以供数据库访问时,没有人眨眼睛,但每个人都在不断地从各种配置文件中生成测试用例。 – davidk01

+0

这不完全一样 - 你使用ORM作为文档。没有逻辑背后的测试是有效的“冒烟测试”,可能会或可能不会对您的项目有好处,但不会取代旧式手写的单元测试,它们实际上测试逻辑,而不仅仅是设置 - >设置 - >获取 –