早上来看到一篇文章，大概讲的是在单元测试中容易用到了Try…Catch语句而容易出现的一个错误，这里想说一下我对单元测试中异常处理的。记得一个牛人曾经说过（实在想不起来谁也搜不到），大概的意思就是“处理一个问题的最好的办法就是不去处理它”。我不知道当时他讲这句话的具体场景是什么，不过我觉得这句话用在单元测试的异常处理中还是比较合适的。

首先来看看两条关于异常处理的原则

• 如果无法处理某个异常，那么就不要捕获它
• 如果捕获到一个异常，那么不要胡乱处理它

单元测试的代码和开发的生产代码，虽然同是程序代码，但是他们存在的意义是不一样的。前者是验证程序的正确性，属于为程序服务的；后者是实现某种功能，属于为客户服务的。然后在看上面的两条异常处理的原则。

• 作为测试代码，如果捕获到一个异常，其实是无法处理它的。从某种角度来看，测试代码和被测代码是不在一个系统中，AUT所抛出的异常，测试代码无法处理，其实也无需处理。
• 假如测试代码捕获了一个异常，那么唯一能做的事情就是把这个异常重新包装一下，或者直接重新抛出给单元测试框架，然后由单元测试框架打印到界面上或者是执行结果中。但是其实我们什么都不做（不用Try…Catch）也能达到这样的效果。

可能会有这样的一些测试用例：在输入某些数据的情况下，该函数会抛出某异常。测试工程师就是要验证有异常的抛出。如果是这样的情况，可以用ExpectedException的Attribute（.NET）来标识出该测试代码必须要抛出该异常，如果没有抛出，该测试就是失败。

所以在单元测试的代码中出现Try…Catch其实是没有必要的，如果是真的觉得要使用Try…Catch才能完成某些用例，那么我觉得可以重新设计测试用例，或者测试用例的实现。Try…Catch增加了测试代码的不确定性，而这样的不确定性会导致诡异的自动化测试脚本的出现。在回归测试的过程中就有可能出现运行10次测试，有2次失败8次成功的情况。

不过在单元测试（集成测试）中Try…Finally语句的使用还是很有必要的，例如我们会把数据库链接释放的代码放在Finally语句块中，保证测试运行无论成功还是失败，都能释放数据库链接，或者其他昂贵的系统资源。

总结：在单元测试（集成测试等……）中，尽量不要使用Try…Catch代码块；如果需要释放昂贵或者有限的系统资源、做清理工作，可以把相关的代码放在Finally代码块中。

参考资料：

异常处理 – MSDN

异常处理原则

理解.NET中的异常

单元测试之新手最容易犯的错误

Related posts:

1. 自动化单元测试要点

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

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

[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。

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

[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对象进来，这样就是两个参数了，很好。

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

[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的一篇文章，我想到用反射去做一个简单的比较，而不用对于每个属性都做对比。（但是我犯了一个错误，我只是“想到”，问没有去重新看一次那篇文章，我写的那个方法有缺点！）

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

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

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这个列表保存了不需要验证的属性名字。整个测试代码如下：

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

[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 List</string><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)) 这句话写的真别扭！也不好！

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

Related posts:

1. 单元测试中的常用测试模式
2. NMock2入门经验
3. 实现数据驱动的CodedUI Test

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的一部分）。

1
2
3
4
5
6
7

[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的客户端进行初始化，保证每一次运行测试前，这个客户端都是“新”的

1
2
3
4
5
6

[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]这样的隐式调用的时候，我觉得这就是银弹，我要充分使用它。但是随着工作的深入，发现这个隐式调用会带来一些问题，然后就慢慢转用了调外部方法，或者直接内联到测试方法中。只有结合实际情况，结合的上下文来运用这些方法，才能真正提高单元测试代码的质量，减少我们的工作量。

Related posts:

1. 用XSD自动生成XML对应的.NET实体类
2. 实现数据驱动的CodedUI Test
3. ASP.NET中配置文件web.config的优先级

1
2
3
4
5
6
7
8

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

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

1
2
3
4
5
6
7
8

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

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

1
2
3
4
5
6
7
8

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

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

Related posts:

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

单元测试，集成测试有什么用？

1. 改进产品质量

软件测试，很多时候围绕着两个问题：

Verification和Validation，常说的双V。前面的Verification就是Is the software built correctly?。后面的Validation就是Have we built the right software?

单元测试，更多的是Verification。所以有时候经过我单元测试和集成测试以后的功能模块，在交给其他同事做功能测试的时候，依然会有一些BUG，这时候开发可能会埋怨我测试得不够完全，诸如此类。但是其实很多时候，我的关注点是单个方法的功能、行为，没有站到更高的位置来测试这个模块。对于这样的问题，开发和测试应该互相体谅，我本人也会提高自身的水平。希望在单元测试和集成测试中也加入更多关于Validation的思考。

有一个提法叫Tests as Specification，单元测试本身其实就是模拟某个模块的使用者（其他的程序）来进行测试。很多时候我写的测试代码也是其他开发人员的参考，尤其在一些事实上或者只是号称自己是敏捷开发的组织里面，测试代码有可能成为详细设计的替代品，因为有可能根本没有详细设计文档。

单元测试的另一个工作就是发现并且定位BUG。对于BUG的定位和重现，在单元测试代码的编写过程中，每个Assert语句后面都要加上尽可能详细的信息，例如导致这个Assert语句失败的每个参数值，期望结果，实际结果等，这些信息可以帮助开发和测试快速定位问题，减少不必要的DEBUG时间。

2. 降低项目的风险

软件测试，其实是用有限来验证无限的一个过程，很多时候做什么样的测试，做到什么样的程度，很多时候都跟风险有关系。

作为产品的安全网，各种测试在项目中都扮演着重要的角色。例如，中美交互的几十个Web Service接口的回归测试，现在有若干个测试，每天定时做回归测试，因为没人知道在美国的服务器会发生什么事情；对于中国的Web Service，在上线前都会通过回归测试，才部署上线。还有全站的Platform Service接口，每次上线前都需要在做回归测试。软件测试的另一个有趣的结论就是：测试只能证明软件有BUG，但是无论什么样的测试，都不能证明被测软件是没有BUG的。问题出来了，我做完回归测试，都通过了，但是我却不能证明这个软件是没有BUG的。其实每次上线，团队都承担着风险，只不过这样的风险在完成回归测试之后，大家上线的信心增加，风险明显地减小。

什么样的测试才是好的测试？

1. 容易运行

什么样的单元测试是容易运行？答案很简单，自动化的单元测试就是容易运行的测试。如果一批测试在运行之前每次都需要重装系统然后还要找一大堆需要依赖的软件来装上，最后还要输入奇怪的命令才能运行，那么就不是一个好的测试（本人真的见过这样的测试，囧）。个人认为，配置好的持续集成系统，可以实现很好的自动化测试；如果没有一个完善的CI，那么一个one click的自动化测试运行也是一个较好的选择。

2. 自动检查结果

一句话：没有自动检查结果，再好的自动化也是白搭。

3. 可重复

一句话：只能运行一次的单元测试也是白搭。

4. 独立

其实测试的独立，也有利于实现可重复。刚做单元测试的时候，曾经犯过这样的错误，我在写A测试的时候，给数据库插入了一条记录，然后我在写B测试的时候，就觉得我为什么要在两个测试中分别创建两条数据？直接用上一个测试的数据就可以了。不过结果还好，我很快就发现这样做是有问题。单元测试的独立，就是运行测试的人可以先运行A测试，也可以先运行B测试，也可以单独运行A或者B测试，甚至可以A和B测试同时运行。

5. 简单

有时候，测试的代码写的有点复杂，嵌套的语句有点多，可能有些人会觉得写出复杂的单元测试代码才能体现自己的水平，但是，我觉得对于单元测试代码来说，应该越简单越好。最好就是顺序执行下来了，不要有什么分支。因为测试代码本身就是也是代码，那么怎么去验证测试代码写的正确呢？答案可能是再写一个测试代码去验证第一个测试代码。这样就会有死循环了。一个简单的假设就是，如果测试代码足够简单，那么就可以认为测试代码是正确的，无需其他代码对之进行测试。

6. 专注

一个测试应该只测试一个点。如果在一个测试里面验证多个测试点，看起来是比较高效的一种做法，但是当测试中有Assert语句抛出异常的时候，很有可能需要花大量的时间才能找到真正错误的代码，这样不利于实现前面提及到的“定位BUG”。

7. 注释

注释其实就是把代码抽取成可阅读的测试用例，如果别人看自己的程序，可以快速理解测试代码；同时注释还能唤醒自己沉睡的记忆和当时的测试思路。

国内做单元测试的测试工程师少，做集成测试、接口测试的也不多，埋头做事,别忘抬头看路。时常总结，提高自我。

Related posts:

1. 《Software Testing》第三章 – 软件测试
2. 单元测试中的异常处理

首先来看一下用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. 单元测试中的常用测试模式

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

这是ZUNE处理时间的一段代码，每年的最后一天（days=365）向第二年的第一天（days要加1）过度的时候会做一个处理。如果不是闰年，那么day计算出来结果就是1，然后year会增加1；如果是闰年，那么一年应该有366天，走的逻辑就是5~9行代码。2008年31号ZUNE死机的原因就是，days=366，years=2008，会出现死循环。下面来写一个单元测试，来测试一下这一段代码块。

[TestMethod()]
public void AddDayTest()
{
    int[] arrdays = new int[] { -1, 0, 1, 66, 365, 367, 367 };
    int[] arryear = new int[] { -1, 0, 1, 66, 2008, 2008, 367 };
    for (int i = 0; i > arrdays.Length; i++)
    {
        int days = arrdays[i];
        int year = arryear[i];
        Class1.AddDay(days, year);
    }
}

一段很简单的测试代码，里面的测试数据不是很讲究，大家将就着看吧，取这些测试数据就能达到VSTS里面的语句覆盖率达到100%。如图：AddDay方法语句覆盖率已经达到100%

下图是具体代码，整个方法体的代码都是浅蓝色，代码都被覆盖到了

回头看看测试数据，虽然达到了100%语句覆盖，但是依然遗漏了“闰年，366天”这样一条数据，只要我们用这条测试数据来测试，就能发现错误了。

下面来说说用VSTS做单元测试，通过一些设置来帮助我们发现类似这个死循环的BUG。在VSTS里面，可以设置每个单元测试的超时时间，默认是30分钟，这样对于发现一些出现死循环的BUG不太有利。很多人都说过，单元测试的一个特点就是–快！因为测试只是检查一小个单元是否能正常工作。如果一个“单元测试”需要几分钟，那么几乎可以很肯定地说，这不是一个单元测试，这个测试肯定跟外界有很多交互，例如读取一个外部文件？读取数据库？请求一个web service等等。在Test run config里面，把超时时间设置为10秒，如果一个测试会导致死循环，那么10秒后，就会提示我们该单元测试出现超时，如图：

设置好了以后运行一下单元测试：

[TestMethod()]
public void AddDayTest1()
{
    int days = 366;
    int year = 2008;
    Class1.AddDay(days, year);
}

出现结果：

很好，我们可以在比较短的时间内发现问题，而不是观察CPU占用率长期达到100%。

总结：现在的代码覆盖率工具，大部分都只有语句覆盖的功能，而语句覆盖 又是众多代码覆盖标准里面最弱的一种。有时候做白盒的测试（单元，集成……），会很容易掉进一个陷阱，就是看着代码覆盖率工具给出的结果，来提高自己测试代码覆盖率。这样代码的覆盖率上去了，但是代码的质量却不见的能有提高。以后做测试的时候，也应该把精力放在关键部分的代码逻辑的验证上，不要老盯着覆盖率往上涨。

Related posts:

1. 自动化白盒测试工具PEX应用实例 – 发现ZUNE死机的BUG
2. 单元测试中的常用测试模式
3. 测试代码重构实例

以前我以为ASP.NET单元测试就运行于WEB服务器上，所以我用Debug来运行，那么ASP.NET单元测试就自动Attach到Web服务器，就能调试了。但是实际上要让ASP.NET单元测试可以调试的话，正确的做法应该是：

1. 在Web.config中，找到<compilation debug=”false”/>这个节点，然后把debug属性改为true
2. 在ASP.NET单元测试代码的最开始处添加这样一句话“System.Diagnostics.Debugger.Break()”
3. 运行该ASP.NET单元测试

在运行单元测试的时候，会有一个提示框出来，说程序遇到一个断点，是否进入调试，当然是选择调试啦。如图：

选中Debug这个程序以后，会有第二个提示框出来，让我们选择用哪个程序来进行调试，可以选择一个合适的VSTS，如图：

选上一个VSTS的实例以后，程序就会停在System.Diagnostics.Debugger.Break()这条语句上，这时候再按一下F5，让程序继续运行，当程序遇到下一个断点，就会停下来了，从此就可以调试ASP.NET的单元测试了。

No related posts.

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了。

1
2
3
4
5
6
7
8
9
10
11

[[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的困难，但是会有以下问题：

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

2. 直接创建HttpContext实例

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

1
2
3
4

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

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

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

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()方法：

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

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的时候就是这样子：

1
2
3
4
5
6
7

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

Related posts:

1. .NET平台上的Memcached客户端介绍
2. 单元测试中三种准备Test Fixture的方法比较
3. 利用序列化和反序列化实现深拷贝

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12

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

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

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

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

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

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

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

下面是一段示例代码：

1
2
3
4
5
6
7
8
9
10

[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)

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

1
2
3
4
5
6
7
8
9
10
11

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

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

1
2
3
4
5
6
7
8
9
10

[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. 异常允许。如果需要测试异常是否在适当的时候抛出的时候，应该应用该模式。

1
2
3
4
5
6
7
8

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

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

Related posts:

1. 测试代码重构实例
2. 在单元测试中应用数据驱动
3. 实现数据驱动的CodedUI Test