进化的测试 » 白盒测试

测试代码重构实例

magus — Sat, 21 Mar 2009 11:17:35 +0000

Martin Fowler的《重构》这本书基本上每个程序员都会看，对于做单元测试的测试工程师来说，测试的代码本身也是程序，也需要重构。最近在看《XUnit Test Patterns》，把以前的做的东西重新梳理了一下，并且落实到新的项目中。

首先来看看一个最原始的单元测试代码：

[TestMethod]
public void GetPaymentAccountByOwnerID()
{
	int ownerId = 1300100000;
	//Delete the account
	TestHelper.DeletePaymentAccountByOwnerId(ownerId);
 
	//Here should be create an account
	PaymentAccount paymentAccount = PaymentGateway.PaymentProvider.GetPaymentAccountByOwnerID(ownerId, AccountOwnerType.NormalUser);
 
	//Verify the payment account instance
	Assert.IsTrue(paymentAccount.AccountID > 0);
	Assert.AreEqual(DateTime.Now.DayOfYear, paymentAccount.CreateTime.DayOfYear);
	Assert.AreEqual(DateTime.Now.DayOfYear, paymentAccount.UpdateTime.DayOfYear);
	Assert.AreEqual(0, paymentAccount.Balance, 0.0001);
	Assert.AreEqual(0, paymentAccount.AvailableBalance, 0.0001);
	Assert.AreEqual(0, paymentAccount.FreezeAccount, 0.0001);
}

以上是个很简单的单元测试代码，应用了AAA原则，首先做好准备（删掉原有的数据），然后执行测试，最后再验证返回结果。看起来很好也很清晰。首先发现一个问题，就是那一堆Assert让人觉得迷惑，究竟想干啥？其实那6句Assert都是验证程序返回的PaymentAccount对象是是否符合设计。我把这些Assert语句提取出来，作为一个方法，让测试代码更加容易让人明白。也就有了版本2。

[TestMethod]
public void GetPaymentAccountByOwnerID()
{
	int ownerId = 1300100000;
	//Delete the account
	TestHelper.DeletePaymentAccountByOwnerId(ownerId);
 
	//Here should be create an account
	PaymentAccount paymentAccount = PaymentGateway.PaymentProvider.GetPaymentAccountByOwnerID(ownerId, AccountOwnerType.NormalUser);
	//Verify the payment account instance
	PaymentAccountAssertion(paymentAccount);
}
 
private void PaymentAccountAssertion(PaymentAccount paymentAccount)
{
	Assert.IsTrue(paymentAccount.AccountID > 0);
	Assert.AreEqual(DateTime.Now.DayOfYear, paymentAccount.CreateTime.DayOfYear);
	Assert.AreEqual(DateTime.Now.DayOfYear, paymentAccount.UpdateTime.DayOfYear);
	Assert.AreEqual(0, paymentAccount.Balance, 0.0001);
	Assert.AreEqual(0, paymentAccount.AvailableBalance, 0.0001);
	Assert.AreEqual(0, paymentAccount.FreezeAccount, 0.0001);
}

以上代码看起来就舒服多了，比较清晰、简短。但是有一个问题，就是后面的3条Assert语句的期望结果是Hard code的，这样很不利于这个自定义的Assert方法的重用。改！我会把那3个〇抽取成这个方法的一个参数，这个自定义的Assert方法变得更加灵活了。代码不贴上来了，因为有一个问题，就是如果我们还需要对PaymentAccount增加一些属性，而这些属性的值都需要被验证，那么这个PaymentAccountAssertion方法的参数就会越来越长。超长的方法参数也是一个不好的味道，我改！改为传递一个期望的PaymentAccount对象进来，这样就是两个参数了，很好。

[TestMethod]
public void GetPaymentAccountByOwnerID()
{
	int ownerId = 1300100000;
	//Delete the account
	TestHelper.DeletePaymentAccountByOwnerId(ownerId);
 
	//Here should be create an account
	PaymentAccount paymentAccount = PaymentGateway.PaymentProvider.GetPaymentAccountByOwnerID(ownerId, AccountOwnerType.NormalUser);
	//Verify the payment account instance
	PaymentAccount expected = new PaymentAccount();
	PaymentAccountAssertion(expected, paymentAccount);
}
 
private void PaymentAccountAssertion(PaymentAccount expectedObject, PaymentAccount paymentAccount)
{
	Assert.IsTrue(paymentAccount.AccountID > 0);
	Assert.AreEqual(DateTime.Now.DayOfYear, paymentAccount.CreateTime.DayOfYear);
	Assert.AreEqual(DateTime.Now.DayOfYear, paymentAccount.UpdateTime.DayOfYear);
	Assert.AreEqual(expectedObject.Balance, paymentAccount.Balance, 0.0001);
	Assert.AreEqual(expectedObject.AvailableBalance, paymentAccount.AvailableBalance, 0.0001);
	Assert.AreEqual(expectedObject.FreezeAccount, paymentAccount.FreezeAccount, 0.0001);
}

第三版出来了，这时候我想起淘宝QA TEAM的一篇文章，我想到用反射去做一个简单的比较，而不用对于每个属性都做对比。（但是我犯了一个错误，我只是“想到”，问没有去重新看一次那篇文章，我写的那个方法有缺点！）

先看看用反射比较属性方法的代码：

public void ObjectAreEqual<t>(T expected, T actual, List<string> excludedProperties)
{
	System.Type myType = typeof(T);
	PropertyInfo[] props = myType.GetProperties(BindingFlags.Public | BindingFlags.Instance);
	foreach (var item in props)
	{
		if (null == excludedProperties || !excludedProperties.Contains(item.Name))
		{
			if (item.PropertyType.Equals(typeof(double)))
			{
				Assert.AreEqual((double)item.GetValue(expected, null), (double)item.GetValue(actual, null), 0.0001);
			}
			else if (item.PropertyType.Equals(typeof(float)))
			{
				Assert.AreEqual((float)item.GetValue(expected, null), (float)item.GetValue(actual, null), 0.0001);
			}
			else
			{
				Assert.AreEqual(item.GetValue(expected, null), item.GetValue(actual, null));
			}
		}
	}
}string>t>

比较简单，就是获取所有的Property，然后做Assert，特别针对了double和float做了处理，因为对于浮点数，Assert.AreEqual方法需要指定一个可接受的误差值。excludedProperties这个列表保存了不需要验证的属性名字。整个测试代码如下：

[TestMethod]
public void GetPaymentAccountByOwnerID()
{
	int ownerId = 1300100000;
	//Delete the account
	TestHelper.DeletePaymentAccountByOwnerId(ownerId);
 
	//Here should be create an account
	PaymentAccount paymentAccount = PaymentGateway.PaymentProvider.GetPaymentAccountByOwnerID(ownerId, AccountOwnerType.NormalUser);
	//Verify the payment account instance
	PaymentAccount expected = new PaymentAccount();
	PaymentAccountAssertion(expected, paymentAccount);
}
 
private void PaymentAccountAssertion(PaymentAccount expectedObject, PaymentAccount paymentAccount)
{
	Assert.IsTrue(paymentAccount.AccountID > 0);
	Assert.AreEqual(DateTime.Now.DayOfYear, paymentAccount.CreateTime.DayOfYear);
	Assert.AreEqual(DateTime.Now.DayOfYear, paymentAccount.UpdateTime.DayOfYear);
 
	List<string> ExcludedProperties = new Liststring><string>() { "AccountID", "CreateTime", "UpdateTime" };
 
	TestUtilityGateway.CustomizedAssert.ObjectAreEqual<paymentaccount>(expectedObject, paymentAccount, ExcludedProperties);
}paymentaccount>string>

下来说说问题：
1. ObjectAreEqual这个方法的最后一个参数不好，那个ExcludedProperties的列表，其实是我懒惰的产物，应该参照子排牛柳的设计方法，把需要比较的属性名传递进去。我当初的想法是，那个自定义Assert方法里面的前3条语句已经验证了我那3个属性了，然后我传个参数进去告诉那个方法“你不要验证这3个属性了”。懒惰啊！这样的设计有个问题，我用个比喻吧，我让我女朋友下楼去超市帮我买点东西，我是应该告诉她，“你帮我买ABCDE”呢？还是应该说“你别给我买FGHIJK…”呢？

2. if (null == excludedProperties || !excludedProperties.Contains(item.Name)) 这句话写的真别扭！也不好！

可以看到这个简单的测试方法的进化，经过了若干个版本，测试方法的可读性，可维护性变好了；而且还写了一个对比两个对象的属性是否一致的公共方法，以后可以重用。测试代码本身也是程序，也需要被重构。

Share and Enjoy:

单元测试中三种准备Test Fixture的方法比较

magus — Tue, 17 Mar 2009 10:09:19 +0000

首先说一下Test Fixture，我不知道怎么样翻译这个Test Fixture，没能搜到一个翻译的比较合适的。最让我气愤的是某人翻译的一本书中，直接把Test Fixture翻译成为测试夹具，这明显就是什么词霸词典硬翻译出来的，我强烈鄙视这样不负责任的翻译行为。

The test fixture is everything we need to have in place to exercise the SUT

我觉得这是一个对Test Fixture的一个很清晰明了的定义，就是运行被测软件所需要的一切东西，这个“东西”不单只是数据，同时还包括对被测软件的准备，例如实例化某个被测方法所在的类，准备数据库的ConnectionString等。通常来说，有三种方法来准备Test Fixture。

1. 内联方式：这种方式就是直接在测试方法中编写准备Test Fixture的代码。用这种方法的缺点是很容易造成代码的重复，出现很多复制粘贴的代码。同时，如果这个SETUP的过程比较复杂，也会降低测试代码的可读性，可维护性。另外的一个问题就是，这种方法很容易会带来测试数据Hard code的隐患。既然有那么多缺点，这种方法还有什么生命力呢？首先，可能对于初学者来说，这种方法是最简单的；其次，在一些只需要准备简单的Test Fixture的场合中，这种方法还是给编写测试的人提供了便利。

2. 委托方式：简单来说就是把Test Fixture的准备抽取为一个外部的方法，然后在需要的时候进行调用。这种方式的好处就是使得测试代码可读性更强，并且这部分的SETUP代码可以重用。而且这种做法可以屏蔽对SETUP过程的认知，使得测试人员的关注点落在真正的测试代码上面，而不是如何SETUP。

3. 隐式方式：很多xUnit框架的实现都提供了不同的隐式SETUP和TEARDOWN。例如MSTEST里面的[TestInitialize]和[TestCleanup]标签，就提供了一种隐式准备Test Fixture的支持。就是在每一个测试方法运行前，都会执行一次标有[TestInitialize]标签的方法。使用这种方法的好处就是写一次就能在各个测试中都实现了Test Fixture的准备，不用每次都显示地调用一个外部方法，不过缺点也不少：

可能会令测试比较难懂，因为这些隐式调用不是必须的，有可能会被遗漏掉。
不能使用哦本地变量来保存对象，只能用test class 里面的filed或者property
变相地使用了全局变量

在做单元测试的过程中，需要灵活地运用这三种Test Fixture的准备方法。例如在我的工作当中，我在以下情况使用到了隐式准备方式：

在某一个测试项目中，由于测试的数据不多，所以我使用了XmlSerializer，把测试的数据都放在一个XML文件中，然后利用XmlSerializer把XML中的数据映射到相应的配置类中。对于这样的情况，这些测试数据在测试运行的全过程中都需要用到，所以我选择了在测试类初始化的时候，只运行1次，来准备这些测试数据（Test Fixture的一部分）。

[ClassInitialize()]
public static void MyClassInitialize(TestContext testContext)
{
    XmlSerializer xmlSerializer = new XmlSerializer(typeof(Config));
    FileStream fs = new FileStream("Config.xml", FileMode.Open);
    config = (Config)xmlSerializer.Deserialize(fs);
}

还是在同一个项目中，我想让每一个测试之间互相不要受到影响，所以我在[TestInitialize()]方法中对于一个Web Service的客户端进行初始化，保证每一次运行测试前，这个客户端都是“新”的

[TestInitialize()]
public void MyTestInitialize()
{
   USi18nService = new InteropWebSerivce();
   USi18nService.Url = config.USi18nAddress;
}

在另外的一个项目中，需要对一个方法进行测试，该方法的功能是根据Email地址从PreSignup表里面获取相关的资料，那么首先要做的就是完成一个PreSignup的操作，才能检查这个方法。而完成PreSignup操作并不是所有的测试都需要的，所以我不选择隐式调用，而是选择委托调用，调用一个外部的帮助方法，来帮助我完成PreSignup操作；同时这个PreSignup的操作在其他一些测试中也是需要的，所以也达到了重用的效果。

那么在什么时候会用到内联方法来准备Test Fixture呢？其实我自己经常用这种方法，有以下一个场景，我需要对一个方法进行测试，这个方法要做的事情就是检查一个电话号码是否符合规范，那么我就会先创建一个List，然后在List里面填充了各种不同的电话号码，然后在后面用一个foreach语句把List里面的数据遍历一遍，可能这些电话号码的数据只在这一个方法里面才有用，所以我没有选择把它抽取成一个方法。

其实不同的单元测试框架有不同的思想，例如在NUnit里面，一个测试类的标签就是叫[Test Fixture]，其实作者的设计思想就是一个测试类，就是一套Test Fixture；如果不是一套Test Fixture，那么不要把测试方法写到一起。其实这三种方法各有所长，在我刚开始学习和尝试做单元测试的时候，我刚接触到类似[Setup][TearDown]这样的隐式调用的时候，我觉得这就是银弹，我要充分使用它。但是随着工作的深入，发现这个隐式调用会带来一些问题，然后就慢慢转用了调外部方法，或者直接内联到测试方法中。只有结合实际情况，结合的上下文来运用这些方法，才能真正提高单元测试代码的质量，减少我们的工作量。

Share and Enjoy:

控制反转有助于提高程序的可测试性

magus — Thu, 12 Mar 2009 04:11:10 +0000

控制反转，英文是Inversion of Control，简称IoC。这个概念在JAVA的Spring框架中比较常见，在.NET的开发中，Ioc或者其的变种依赖注入DI（Dependency Injection）是不太常见的。一般来说，类A要使用类B，类A会在其内部对类B进行控制，比较典型的做法就是在类A中创建一个类B的实例；而控制反转，就是把一个已经创建好的类B实例交给类A去控制。
例子：

有一个Member的类，他需要调用一个Web service的客户端接口，在这个类的构造函数里面，创建了一个WebServiceClientA对象。这里的WebServiceClientA类是实现了WebServiceClient接口的。

class Member
{
    WebServiceClient client;
    Member()
    {
        client = new WebServiceClientA("10.60.0.11");
    }
}

问题来了，对于这个类，我们怎么去测试？在构造函数里面已经初始化了一个WebServiceClientA，并且指定了这个WebServiceClientA的IP是10.60.0.11。那假如说开发环境不能连接到这台服务器上，那么怎么测试。这个问题可以通过对IP地址这个参数写到配置文件里面就能解决，其实这个跟IoC没有什么关系。

class Member
{
    WebServiceClient client;
    Member()
    {
        client = new WebServiceClientA(ConfigurationManager.AppSettings["ServerIP"]);
    }
}

现在又有问题了，如果WebServiceClientA类没有完成，但是此时却要进行测试，怎么办？又假如说WebServiceClientA类是很难被创建的，怎么办？Mock也有劲使不上啊。
其实在构造函数里面是不应该有创建对象的操作，也就是尽可能不要有new操作，我们把WebServiceClient作为构造函数的一个参数，传递进去，这样程序的可测试性就有了提高，这时候可以对WebServiceClient使用Mock对象了。

class Member
{
    WebServiceClient client;
    Member(WebServiceClient c)
    {
        client = c;
    }
}

这跟著名的好莱坞原则(Hollywood Principle)有几分相似，don’t call us, we’ll call you。你不要自己创建一个实现了WebServiceClient接口的对象，我给你传一个。

Share and Enjoy:

PEX-.NET自动化白盒测试工具的介绍(1)

自动化白盒测试工具PEX应用实例 – 发现ZUNE死机的BUG

magus — Sat, 10 Jan 2009 06:26:34 +0000

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

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

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

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增加一些限制，使得生成的测试数据更加有代表性，更加有意义。

[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属性可要可不要。最后测试如下：

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

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

Share and Enjoy:

在C#单元测试中使用HttpContext的简单解决办法

magus — Sat, 20 Dec 2008 07:31:59 +0000

场景：最近在测试一个.NET的Http Module，这个Module是用来做URL重写的。刚开始进展的比较顺利，因为该Module里面的方法参数基本上都是String，后来这个Module进行了一下重构，所有参数都变成了HttpContext了，这就直接导致原来的单元测试都跑不起来了，接着就开始了弄HttpContext了。

1. 采用Visual Studio自带的ASP.NET单元测试

刚开始我看了一下被测试的代码，虽然说用到了HttpContext，但是有很多地方我都可以绕过去的，意思就是这个HttpContext只是名以上需要的一个参数，只要它不是NULL就可以了，并不影响我的测试，所以我采用了ASP.NET Unit Test的办法来获取一个HttpContext，这个方法实现起来是最简单的，但是会有一些问题，后面会提及到。

首先新建一个WEB项目，然后把被测的Http Module挂到这个新建的WEB项目中。然后就可以配置ASP.NET单元测试，把原来一般的单元测试改造成为一个ASP.NET的单元测试。步骤如下，在测试方法前面加上以下属性

1
2
3

[HostType("ASP.NET")]
[UrlToTest("http://localhost:6988/Default.aspx")]
[AspNetDevelopmentServerHost("D:\\MS_Code\\Public\\UrlRouter.WebTest", "/")]

[UrlToTest] — 这个属性指定了运行该单元测试时的URL

[HostType] — 一般的单元测试是在VSTest的宿主进程下运行，所以是没有HttpContext的；如果作为ASP.NET单元测试，那么必须要在ASP.NET宿主进程下运行

[AspNetDevelopmentServerHost] — 由于我使用了ASP.NET Development Server 作为测试的主机服务器，而不是IIS；所以我需要设置这个属性来指定Web应用程序的完整路径。这里我需要把目录指向刚才新建的WEB项目的路径中。这样子就可以在单元测试中直接使用HttpContext.Current来获取一个HttpContext了。

[[TestMethod]
[HostType("ASP.NET")]
[AspNetDevelopmentServerHost("D:\\MS_Code\\Public\\UrlRouter.WebTest", "/")]
[UrlToTest("http://localhost:6988/Default.aspx")]
public void Fuseaction_PUT()
{
    handler = new UrlMapHandler(HttpContext.Current);
    Assert.IsNotNull(handler);
    result = handler.ExecuteUrlMap();
    StringAssert.Contains(result.Url, "expected string");
}

这样子初步解决了需要HttpContext的困难，但是会有以下问题：

对HttpContext的内容不可控
需要运行ASP.NET Development Server
不能进行调试

2. 直接创建HttpContext实例

基于刚才提到的3个不足，我决定直接创建一个HttpContext来解决问题。还好，HttpContext有公开的构造函数，这个构造函数需要接受一个HttpWorkerRequest作为参数，HttpWorkerRequest是一个抽象类，就是不能直接对之实例化啦，不过好消息是，微软有一个简单的类“SimpleWorkerRequest”，这个类实现了HttpWorkerRequest类；下面是一段简单的代码

TextWriter tw = new StringWriter();
HttpWorkerRequest wr = new SimpleWorkerRequest
("default.aspx", "friendId=1300000000", tw);
HttpContext.Current = new HttpContext(wr);

这样子就能在单元测试里面用到HttpContext了，好处有：

可以控制HttpContext的内容了，对于URL重写这部分来说，会比较关心请求路径，还有queryString，这两个可以在实例化SimpleWorkerRequest的时候，作为参数传递进去。
不需要ASP.NET Development Server。这个很重要，因为可以满足一个自包含(self-contained)的单元测试的要求
可以调试

3.改良后的方案

到此，世界很美好，测试进行的很顺利。好日子没过多久，我又遇到一个问题，这个URL重写模块，还应用了一个规则引擎，其中进行了大量对HOST判断的操作，很不幸，用刚才的方法创建的HttpContext，它返回的Request.Url中，HOST永远都是127.0.0.1，很郁闷。这时候，一个所有做.NET的人都需要的屠龙刀派上用场了！.NET Reflector，用Reflector打开System.Web.dll，找到System.Web.Hosting这个命名空间，然后找到SimpleWorkerRequest这个类，发现里面的GetLocalAddress()方法，发现里面就是Hard-Code了一个地址：127.0.0.1；好了，知道问题在哪里了，着手写一个新的类，这个类继承SimpleWorkerRequest，然后重写他的GetLocalAddress()方法：

public class MyWorkerRequest : SimpleWorkerRequest
{ 
    private string localAdd = string.Empty;
 
    public MyWorkerRequest(string page, string query, TextWriter output, string address)
        : base(page, query, output)
    {  
        this.localAdd = address;
    }
 
    public override string GetLocalAddress()
    {
        return this.localAdd;
    }
}

这样子，实例化HttpContext的时候就是这样子：

Thread.GetDomain().SetData(".appPath", "c:\\inetpub\\wwwroot\\webapp\\");
Thread.GetDomain().SetData(".appVPath", "/");
TextWriter tw = new StringWriter();
String address = "home.myspace.cn";
HttpWorkerRequest wr = new MyWorkerRequest
("default.aspx", "friendId=1300000000", tw, address);
HttpContext.Current = new HttpContext(wr);

需要注意的是，对于.appPath和.appVPath的设置是必须的，因为在SimpleWorkerRequest的构造函数中，会取这两个数值。
经过这样的改造，基本上已经满足了测试的需求了。

总结一下：

这个事情居然用了1天多时间，后来发现解决的办法就在我订阅的博客里面就有，以后遇到什么难题先找一个Google Reader。
多用.NET Reflector，Visual Studio经常让你看meta data，那些meta data对我们来说一点用处都没有，还是Reflector好啊。

Share and Enjoy:

单元测试中的常用测试模式

magus — Mon, 15 Dec 2008 13:15:44 +0000

单元测试跟软件设计一样，有一些常用的模式，这篇文章是介绍一些常用的模式，其中的示例是C#代码，都比较简单，我想大家都能看懂。下面进入正题：

1. 准备，执行，断言(Arrange, Act, Assert)。这种模式是非常常见的，套用这种模式进行单元测试通常的做法如下：

准备测试环境，测试数据等
执行被测试方法
用断言来验证执行结果

下面是一段测试代码，被测方法的功能是把字符串中每个单词的首字母转为大写，特殊字符用下划线替代。

[TestMethod()]
public void CapitalizeTest()
{
//准备数据
string input = "hello world!";
string expected = "HelloWorld_";
//执行测试
string actual;
actual = TextHelper.Capitalize(input);
//验证结果
Assert.AreEqual(expected, actual);
}

2. 构造函数测试。这种模式适合对类中某些特殊的属性进行测试，被测的属性都有一个特点–它们都是不变量；例如数组的初始化以后，其容量是不会变化的，无论这个数组对象被什么样的外部方法调用。一般的做法如下：

创建一个实例
对该实例进行外部调用
用断言来验证执行结果

下面是一段代码；首先创建一个数组，然后使用该数组，最后验证该数组的大小有没有变化

[TestMethod]
public void TestInvariant()
{
//创建一个实例
int capacity = 5;
int[] intArray = new int[capacity];
//进行调用
for (int i = 0; i &lt; intArray.Length; i++)
{
intArray.SetValue(i, i);
}
//验证结果
Assert.AreEqual(capacity, intArray.Length);
}

3. 反向关联(Roundtrip)。这种模式适合于被测方法有一个可逆方法的情况下使用。它的数学证明是：f^-1(f(x)) = x

下面是一段示例代码：

[TestMethod]
public void RoundTripTest()
{
string str = "10";
//把字符串转换为整数，然后再转换为字符串
int i = Int32.Parse(str);
string finalString = i.ToString();
//验证结果
Assert.AreEqual(str, finalString);
}

4. 经过处理的反向关联(Sanitized Roundtrip)。上面说的反向关联有一个缺点，就是如果输入的字符串为” 10″，那么就有点问题了，因为整数10转换为字符串是不会转换为” 10″的，这个模式的数学证明是：f^-1(f(f^-1(x)))=f^-1(x)

以下示例可以看做是上一段代码的加强版

[TestMethod]
public void SanitizedRoundTripTest()
{
string str = " 10 ";
//先把字符串转换为整数，然后把整数转换为字符串，最后把字符串转换为整数
int i = Int32.Parse(str);
string intermediate = i.ToString();
int roundtripped = Int32.Parse(intermediate);
//验证结果
Assert.AreEqual(i, roundtripped);
}

5. 状态关联。这种模式很常见，就是对于调用某个类的方法，会改变这个类内部的状态，而这个改变可以用其他方法来间接地验证。

一段对列表进行简单测试的代码

[TestMethod]
public void InsertContains()
{
string input = "some string";
List<string> list = new List<string>();
list.Add(input);
Assert.IsTrue(list.Contains(input));
list.Remove(input);
Assert.IsFalse(list.Contains(input));
}

6. 异常允许。如果需要测试异常是否在适当的时候抛出的时候，应该应用该模式。

[TestMethod,ExpectedException(typeof(IndexOutOfRangeException))]
public void ExpectedException()
{
//创建一个长度为5的数组
int[] array = new int[5];
//尝试给该数组的第六位赋值，应该抛出IndexOutOfRangeException异常
array[6] = 1;
}

以上六种模式是单元测试中比较常见的，但并不是单元测试的全部。了解这些模式，对于平时的工作是很有帮助的。

Share and Enjoy: >

PEX-.NET自动化白盒测试工具的介绍(1)

magus — Thu, 11 Dec 2008 08:20:22 +0000

PEX的全称是(Program EXploration)，是一款在.NET下可应用的自动化白盒测试工具，来自于微软研究院。PEX通过分析代码来自动生成测试用例。对于程序里面的每一行代码，PEX都会尽可能地生成合适的输入值来达到提高覆盖率的目标。同时PEX还会分析代码中的分支，生成覆盖更多分支的测试代码（输入数据）；PEX在执行代码的同时会监控和分析代码的控制流和数据流，了解程序的行为。每运行完单一个测试以后，PEX会选择一条在前面的测试中没有覆盖到的路径，并且尝试执行它。这一切都是约束求解算法来实现的，官方文档中提到的是一个叫Z3的约束求解器。因为PEX了解被测代码内部结构和行为，所以它不是一个简单地输入随机参数的黑盒测试工具。PEX不会尝试枚举所有可能的输入，事实上也不可能枚举完所有的可能输入。

下面来看看如何利用PEX来帮助提高软件的质量吧。

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

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

create a class project

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

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就能把这段代码段加到我们的代码中

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

Share and Enjoy: