进化的测试

在12月的时候，我在博客里面介绍了一个自动化单元测试工具–PEX。在上一篇博客中，又讲述了微软ZUNE在闰年最后一天死机的原因。现在把这两篇文章串起来，跟大家分享一下如何用PEX帮助改善代码的质量。

首先来看一下用PEX测试ZUNE处理日期的方法的结果，如图：

大家可以复习一下被测代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

while (days > 365)
{
	if (DateTime.IsLeapYear(year))
	{
		if (days > 366)
		{
			days -= 366;
			year += 1;
		}
	}
	else
	{
		days -= 365;
		year += 1;
	}
}

从图中可以看到PEX总共运行了73次，产生了5个测试用例，其中2个测试用例是运行失败的，还有2个测试用例在运行过程中超出了设定的运行次数（其实这2个用例就找到了ZUNE的那个BUG）。我们分别来看看PEX生成的几个用例。第一行测试数据是days=0, year=1；这条测试数据是能够通过测试的。第二行和第三行测试数据是测试运行失败的，days是一个很大的整数，这两个测试虽然是失败的测试，但是不需要关心，因为实际中日期不可能到达那个数值，所以可以认为这是无效的测试数据。再来看最后的两条测试数据，都是超过了单个测试运行的次数，可以怀疑其中有死循环。

经过PEX初步的诊断，我们需要给PEX增加一些限制，使得生成的测试数据更加有代表性，更加有意义。

1
2
3
4
5
6
7
8
9

[PexMethod]
public void abcd(int days, int year)
{
	PexAssume.IsTrue(days < 367);
	PexAssume.IsTrue(days > 0);
	PexAssume.IsTrue(year < 3001);
	PexAssume.IsTrue(year > 0);
	Class1.AddDay(days, year);
}

在调用被测方法之前，是4条PexAssume语句，这4条语句可以告诉PEX，需要生成的测试数据中days是在1到369之间取值， year是在1到2999之间取值。有了这样的限制以后，PEX产生是结果会更加好，见下图：

点击最后一条测试结果，查看Details：

我们可以看到已经生成了普通的单元测试了。这个单元测试就可以留着以后做回归测试用了。

把他复制到相应的CS文件中，然后删除掉Ignore属性，Description属性可要可不要。最后测试如下：

1
2
3
4
5

[TestMethod]
public void abcd24()
{
	this.abcd(366, 400);
}

PEX可以说是一个革命性的测试工具，如果有兴趣的朋友可以上MSDN论坛的PEX版块学习。

Related posts:

1. 微软ZUNE死机原因–单元测试百分百语句覆盖率是不够的
2. 测试代码重构实例
3. 单元测试中的常用测试模式
4. 单元测试中三种准备Test Fixture的方法比较
5. PEX-.NET自动化白盒测试工具的介绍(1)