前一阵子需要测试一个搜索在线会员的功能，如果一个用户是在线的，那么他所能够被搜索到的信息都会作为一条记录，保存在一个表中，主要的字段有5个，也就是根据这5个字段的信息可以查询出用户想要的在线会员。一个简单的方案就是写一个比较复杂的存储过程，然后根据5个输入来查询出不同的结果，不过DBA说在SQL SERVER中进行逻辑运算的性能不是很好，所以开发人员写了12条存储过程，分别对应不同的组合，那么对于我做集成测试来说，我起码要有12个测试方法对应这12条存储过程。同时我还要设计一定数量的测试数据，供我查询测试，而比较要命的是，这些测试数据随着我对这个功能的理解的深入，在不断地增加，结果就是如果我写第一个测试的时候，我准备的数据是30条，OK，测试通过；等我写到第五个测试的时候，测试数据可能有40条了，当我用这40条测试数据重新指向第一个测试的时候，FAILED!!!这让人非常郁闷。所以我想到了能不能用round trip的方法来进行测试。做一个比喻，假如说我想证明WIN7的计算器程序是正确的，那么可以把相同的计算在WIN XP的计算器中跑一遍，如果两者结果一样，那么我可以认为WIN7的计算器程序也是正确的（如果XP的计算器有错怎么办？先别较真，有风险，但很小）。

我的做法就是，准备一些数据，首先用SUT进行查询，然后用LINQ进行查询，如果两者查询结果一致，那么可以认为程序是正确的，否则就是两者之一存在问题。

首先准备一些测试数据，保存为XML文件，第一方便对测试数据进行CRUD，第二可以用XmlSerializer把这些数据转换为对象，方便用LINQ查询。

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

< ?xml version="1.0" encoding="utf-8" ?>
<onlinefriends>
    <friends>
        <onlinefrienddata>
            <friendid>1300010000</friendid>
            <province>北京市</province>
            <city>北京市</city>
            <age>18</age>
            <gender>2</gender>
            <hasphoto>true</hasphoto>
        </onlinefrienddata>
        <onlinefrienddata>
            <friendid>1300010002</friendid>
            <province>北京市</province>
            <city>北京市</city>
            <age>27</age>
            <gender>2</gender>
            <hasphoto>false</hasphoto>
        </onlinefrienddata>
        <onlinefrienddata>
            <friendid>1300010004</friendid>
            <province>广东省</province>
            <city>广州市</city>
            <age>45</age>
            <gender>1</gender>
            <hasphoto>true</hasphoto>
        </onlinefrienddata>
    </friends>
</onlinefriends>

然后需要有一个类，利用XmlSerializer来反序列化这些测试数据

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

[XmlRoot("OnlineFriends")]
public class OnlineFriends
{
	private bool IsEmpty = true;
 
	private static OnlineFriends fs = new OnlineFriends();
 
	private OnlineFriends()
	{ }
 
	public static OnlineFriends Instance
	{
		get
		{
			if (fs.IsEmpty)
			{
				fs.Deserialize();
			}
			return fs;
		}
	}
 
	private void Deserialize()
	{
		var serialzer = new XmlSerializer(typeof(OnlineFriends));
		using (XmlReader xmlreader = XmlReader.Create("OnlineFriends.xml"))
		{
			fs = serialzer.Deserialize(xmlreader) as OnlineFriends;
			fs.IsEmpty = false;
		}
	}
 
	public class OnlineFriendData
	{
		[XmlElement("FriendId")]
		public int FriendId { get; set; }
 
		[XmlElement("Province")]
		public string Province { get; set; }
 
		[XmlElement("City")]
		public string City { get; set; }
 
		[XmlElement("Age")]
		public int Age { get; set; }
 
		[XmlElement("Gender")]
		public byte Gender { get; set; }
 
		[XmlElement("HasPhoto")]
		public bool HasPhoto { get; set; }
	}
 
	[XmlArray("Friends")]
	[XmlArrayItem("OnlineFriendData")]
	public OnlineFriendData[] Friends { get; set; }
}

数据的准备工作就差不多了，看一个简单的测试。首先这个测试方法会重新初始化测试数据，然后查询27岁的在线会员，查询出来的结果保存在ids的INT列表中。OnlineFriends.Instance.Friends对象中保存了所有在线好友的数据，它是一个实现了IEnumerable接口的类，所以可以使用LINQ相关的扩展方法。

在OnlineFriends.Instance.Friends.Where(x => x.Age == age)语句中，“x => x.Age == age”是一个应用了Lambda表达式的匿名委托，整个语句的意思就是在OnlineFriends.Instance.Friends这个集合中，找到年龄==age的元素。

不过找到了以后还不行啊，SUT返回的是INT列表，而刚才查到的是OnlineFriendData对象的集合，接下来可以用Select(y => y.FriendId).ToList()对集合做一个投影，只取出FriendId属性，并且转换为INT列表。

最后用CollectionAssert.AreEquivalent()方法对两个INT列表进行比较，看列表是否相等。

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

[TestMethod]
public void GetOnlineFriendsIdList_Query_Age_LowerUpperDiffOne()
{
	//重新初始化测试数据
	TestHelp.InitForSearch();
	int age = 27;
	OnlineFriendQuery query = new OnlineFriendQuery();
	query.AgeLowerBound = age;
	query.AgeUpperBound = age;
             //根据条件查询在线会员，在这里就是要查询27岁的会员
	List<int> ids = FriendListGateway.FriendListProvider.GetOnlineFriendsIdList(query, MyAllPc);
 
	//Two collects are equivalent
	CollectionAssert.AreEquivalent(OnlineFriends.Instance.Friends.Where(x => x.Age == age).Select(y => y.FriendId).ToList</int><int>(), ids);
}
</int>

假如使用我最开始的测试方法（就是先准备测试数据，然后人工统计一下里面有多少个27岁的数据，最后进行比较），我在完成了这一条测试以后，接下来还要小心翼翼地添加测试数据，不能再添加年龄是27岁的数据，要不然就会影响到测试结果。但是应用了LINQ以后，我在后续的测试数据设计中就无需要担心新设计的测试数据会对老的测试造成影响。甚至我还可以用程序生成各种不同的数据，填入数据库，供我测试用。

Related posts:

1. 用XSD自动生成XML对应的.NET实体类
2. 在单元测试中应用数据驱动
3. 在C#单元测试中使用HttpContext的简单解决办法

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. Linq to Object在测试中的应用
2. 用XSD自动生成XML对应的.NET实体类
3. PEX-.NET自动化白盒测试工具的介绍(1)

早上来看到一篇文章，大概讲的是在单元测试中容易用到了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.