1. 关于测试类名称和测试方法名称

为了把Pex和其他的单元测试方法区分开来，本人选择了把所有Pex的测试都以PexTest作为方法名和类名的前缀。因为Pex会根据已经写好的PUT(Parameterized Unit Test)生成一般的单元测试代码，规则可以自定义，一般都是PUT的名字然后跟上01，02，03……如果我们以PexTest作为前缀，那么就比较容易区分PexTest和普通的单元测试。

2. 每个PexTest都会生成一些普通的单元测试代码，这些代码都是存放在一个叫{TestMethodName}.g.cs的文件中，对于这个文件里面代码，不建议手动修改。

3. 在组织测试代码的时候，应该吧PexTest和一般的单元测试分开，如图：

4. 如果需要测试Singleton实例中的方法，需要给这个实例创建一个带有[PexFactoryMethod]属性的方法，来告诉Pex如何获得Singleton实例。例如：

1
2
3
4
5
6
7
8

public static partial class CommentProviderFactory
{
	[PexFactoryMethod(typeof(CommentProvider))]
	public static object Create()
	{
		return CommentProvider.Instance;
	}
}

5. Pex有时候会尝试着对.NET自带的代码也进行测试，如果遇到这种情况，可以在Pex Exploration Results窗口中把相关的方法标记为不检测。

6. 如果修改了PUT，那么原来在{TestMethodName}.g.cs自动生成的测试方法有可能没法运行，可以把这个文件删掉，然后让Pex重新生成测试。

Related posts:

1. 用XSD自动生成XML对应的.NET实体类
2. 利用序列化和反序列化实现深拷贝
3. PEX-.NET自动化白盒测试工具的介绍(1)

首先来看一下用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版块学习。

No related posts.

1. 首先，安装PEX。PEX现在有2个Flavor，支持2个版本的Visual Studio，分别是VSTS2010和VSTS2008，这两个版本的PEX在功能上没有区别，只是在许可证上有区别。本文是以VSTS2008版本作为示例。

2. 建立一个C#的Class Library项目

create a class project

3. 新建一个类，并且添加一个静态方法。这个方法是把输入的字符串格式化为首字母大写的格式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public static string Capitalize(string value)
{
	var sb = new StringBuilder();
	bool word = false; // are we writing a word
	foreach (var c in value)
	{
		if (char.IsLetter(c))
		{
			if (!word)
			{
				sb.Append(char.ToUpper(c));
				word = true;
			}
			else
				sb.Append(c);
		}
		else
		{
			if (char.IsPunctuation(c))
				sb.Append('_');
			word = false;
		}
	}
	return sb.ToString();
}

4. 这时候，可以创建一个传统的单元测试，但有了PEX，我们希望用PEX

5. 在该静态方法体内，点击右键，选择“Run Pex Explorations”，就可以运行PEX

6. PEX会编译这个类，并且运行这个方法，监控测试的运行，对于这个简单的方法，很快就会获得结果。在标题栏可以看到，运行了123次测试，其中有1个测试是失败的；失败的用例就是图中被圈出来的那一条。

7. 点击选中测试结果中有异常的测试行，会看到以下菜单，可以做以下操作：

(1)保存该测试为普通的单元测试
(2)自动添加代码来避免该错误的发生
(3)允许此异常在程序中出现
(4)把所有信息发送到文本或者剪切板，这里所有信息包括Detail和Stack trace，如果TFS里面配置了Work Item，还能直接发送到相应的Work Item中

8. 现在我们让PEX帮我们修正一个错。选择Add Precondition，会看到如下菜单。上半部分告诉用户，PEX会做那些操作，下半部分就是选中操作的具体内容，这里就是加上一段对输入是否为空的判断

9. 点击Apply就能把这段代码段加到我们的代码中

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

public static string Capitalize(string value)
{
	//
 
	if (value == (string)null)
		throw new ArgumentNullException("value");
	//
	var sb = new StringBuilder();
	bool word = false; // are we writing a word
	foreach (var c in value)
	{
		if (char.IsLetter(c))
		{
			if (!word)
			{
				sb.Append(char.ToUpper(c));
				word = true;
			}
			else
				sb.Append(c);
		}
		else
		{
			if (char.IsPunctuation(c))
				sb.Append('_');
			word = false;
		}
	}
	return sb.ToString();
}

OK！PEX帮助我们找到一个Bug并且修复了它。

本文对PEX进行一个简单的介绍，当然PEX不仅仅是那么简单，还有很多丰富的内容，例如Parameterized Unit Test，Code Contracts等等，后面打算深入研究一下PEX，挖掘一下相关的功能。预告一下，下一篇会介绍如果利用PEX写参数化单元测试(Parameterized Unit Test)

更多的参考：

Pex官方网站

Pex在MSDN上的论坛

主要参考文档：Code Digger Tutorial

No related posts.