博客园_風語·深蓝

8天学通MongoDB（实际操作版）——第一天基础入门

2012-05-03T09:45:00Z

为了方便练手，便跟着《8天学通MongoDB》系列实际操作，并做学习日记记录。

一：下载

到MongoDB官方下载页面，有32位和64位版本，需要注意两点：

根据业界规则，偶数为“稳定版”（如：1.6.X，1.8.X），奇数为“开发版”（如：1.7.X，1.9.X)，这两个版本的区别相信大家都知道吧。
32bit的mongodb最大只能存放2G的数据，64bit就没有限制。

我选择的是2.0.4的64位版。下载后解压到C盘，把文件夹名改为mongodb。

二：启动

启动之前，在C:\mongodb目录下添加子目录db，用于存放mongodb的数据。
在命令行中，输入以下代码
代码
最后要看下是否开启成功，从图中的信息中获知，mongodb采用27017端口，那么我们就在浏览器里面键入“http://localhost:27017/”，打开后，mongodb告诉我们在27017上Add 1000可以用http模式查看mongodb的管理信息（即http://localhost:28017/）

三：基本操作

接下来实践Mongodb的增删查改，mongod是MongoDB的服务器端启动程序，而mongo则是MongoDB的Shell，可以简单认为是客户端，同时也是个js的编译器，默认连接到test库。

代码

insert操作
db.person.insert({"name":"jack", "age":20})
db.person.insert({"name":"joe", "age":25})
通过以上两行命令，插入了两行记录到集合person中。需要注意的是，若集合person若不存在，则会直接创建一个新的。
find操作
db.person.find()
db.person.find({"name":"joe"})
不带任何参数的find方法会列出该集合中所有的记录
update操作
db.person.update({"name":"joe"},{"name":"joe","age":35})
需要注意的是，update中的第二个参数，即目标值，必须是包含完整的字段，否则其他字段会变成Null值
remove操作
db.person.remove()
需要注意该操作若不带任何参数，会删除所有数据，且不可撤回。

本文链接

构建Ubuntu Server试验环境

2011-12-18T15:38:00Z

目标：

现在在Linux下有很多非常强大的开源服务器组件，比如Redis, Memcached, RabbitMQ, MongoDB, Hadoop等，非常值得研究，因此准备着手做一个Ubuntu的虚拟机，在里面安装这些服务，供外部调用测试。

第一步：使用Windows Server 2K8R2中的Hyper-V作为虚拟机宿主，因为我的电脑只有无线网卡，而Hyper-V默认不支持使用无线网卡作为虚拟机的网卡，因此需要做以下操作：

首先，在Virtual Network Manger里面天机一个Internal Only类型的虚拟网络：

然后，在Network Connections面板中，把无线网卡和新建的这个虚拟网络设备之间创建桥连接，创建好后如下图所示：

这样就算是设置好虚拟机的网络了，接下来开始Ubuntu Server的安装。

第二步，配置Ubuntu Server。

1. 设置虚拟机名和存放位置

2. 设置虚拟机的内存大小

3. 设置虚拟机使用的网卡，设置为刚刚添加的Virtual Internet连接

4. 为虚拟机系统设置硬盘，Hyper-V缺省创建的虚拟硬盘会根据实际使用增大，不会一开始就划定设定的大小

5. 为虚拟机安装系统，挂接Ubuntu Server的安装盘，这里我选择的是ubuntu-11.10-server-amd64.iso，然后这就完成了虚拟机的基本配置。

第三步，开始在虚拟机中安装Ubuntu Server了。

1. 启动虚拟机，进入安装界面，首先是选择安装提示语言类型，为了更好的兼容性，请选择English

2. 接下来，会出现具体的安装提示，直接按回车选择Install Ubuntu Server就行了

3. 选择系统的缺省语言，还是选择English, 国家选择United States

4. 在Configure the network时，会提示无法找到网卡，先点继续安装

5. 为虚拟机的Ubuntu Server设置一个机器名：

6. 设定时区，选择Asia里的Chongqing

7. 设定Ubuntu Server的磁盘分区，选择缺省的Guided – use entire disk and set up LVM即可，接下来几步都选Yes和缺省值即可

8. 完成基本的安装之后，安装向导会要求输入一个日常使用的帐号。（System Admin是用户名，sa是帐号ID，密码使用1234）

9. 接下来的Home目录是否加密选No, Http Proxy空着以及不自动更新升级

10. 最后是附加软件安装选择，请勾上Open SSH Server, LAMP Server，然后继续，等待片刻之后，完成Ubuntu Server的初步安装。

第四步，配置Ubuntu Server环境。

1. 首先要做的肯定是配置Ubuntu Server的IP地址和DNS

Ubuntu的网络配置信息放在 /etc/network/interfaces 中，而DNS信息在/etc/resolv.conf中

首先使用sudo –s切换为root用户，再使用nano /etc/network/interfaces和nano /etc/resolv.conf命令分别设置IP和DNS，最后使用/etc/init.d/networking restart应用设置的IP地址和DNS。

可以使用ifconfig命令和ping命令来验证配置情况。

2. 因为此前在安装阶段已经选择了OpenSSH和LAMP，因此可以在宿主机器的浏览器中访问虚拟机里的Apache Server，验证是否工作正常；同时也可以使用pietty等SSH终端去连接虚拟机了

3. 执行sudo apt-get update，更新当前的Ubuntu Server，这可能会需要十几分钟

4. 再执行sudo apt-get install build-essential安装基本的编译环境。

5. 接下来我们就可以开始安装更多的Linux Service了。

第五步，安装Redis

1. 访问官方网站的下载页http://redis.io/download , 可以在下面的Installation节找到类似如下的安装命令示例，然后在Ubuntu Server环境中执行以下命令：

$ wget http://redis.googlecode.com/files/redis-2.4.4.tar.gz
$ tar xzf redis-2.4.4.tar.gz
$ cd redis-2.4.4
$ make$ sudo make install

2. 接下来是配置init启动脚本，命令行如下：

$ wget https://github.com/ijonas/dotfiles/raw/master/etc/init.d/redis-server
$ sudo mv redis-server /etc/init.d/redis-server
$ sudo mv redis.conf /etc/redis.conf$ sudo useradd redis$ sudo mkdir -p /var/lib/redis$ sudo mkdir -p /var/log/redis$ sudo chown redis.redis /var/lib/redis$ sudo chown redis.redis /var/log/redis

3. 修改redis.conf文件，主要修改点节点是：

#是否作为后台服务运行，默认为no daemonize yes #客户端空闲多久会超时，默认为0（即永不过期） timeout 300 #设置日志文件位置，默认为运行目录的stdout文件 logfile /var/log/redis/redis.log #设置数据文件存放目录，默认为./ dir /var/lib/redis

4. 把Redis设为开机启动，然后启动Redis，并进行验证

sudo update-rc.d redis-server defaults

sudo /etc/init.d/redis-server start使用redis-cli连接服务器进行测试之后如下图所示：

（未完待续）

本文链接

单元测试培训系列：（二）单元测试与Visual Studio

2011-07-10T16:16:00Z

单元测试需要有一定的工具和框架的支撑，在早期，一般我们使用的都是NUnit这套单元测试框架进行。后来微软在Visual Studio中集成了单元测试功能后，提供了更为强劲的功能以及集成整合能力，就没有必要再继续使用Nunit了。

这一章节，主要就是介绍Visual Stuido中常见的单元测试相关的Attribute的功能和使用场景。

基本类Attribute

TestClassAttribute

用于标识包含测试方法的类。任何一个单元测试类，必须在类上添加该Attribute，否则不会被Visual Studio识别为单元测试类，里面的所有方法也无法正确识别；

TestMethodAttribute

用于标记测试方法。只有添加了该Attribute的方法才会被识别为单元测试方法，才会被添加到Test List中；

PriorityAttribute

用于标记单元测试方法的执行优先级，即先后顺序。（但我测试时候未能生效，别的朋友有成功过，具体原因不详）

DescriptionAttribute

标记并描述当前单元测试方法，会出现在Test List中（默认不显示这列，需要手动添加），方便在运行测试时，方便的了解测试方法的含义

TestPropertyAttribute

传递Key/Value元数据的一个Attribute，本身没什么特别意义，允许在一个方法上标记多个。

初始化与清理类Attribute

此类别的所有属性都必须写在静态方法上

AssemblyInitializeAttribute

当一个程序集中第一个单元测试方法被执行前会执行该方法，用于初始化操作

ClassInitializeAttribute

当第一次执行当前类中的单元测试方法前会执行该方法，用于初始化操作

TestInitializeAttribute

当前类中的每个单元测试方法都会先执行该方法

TestCleanupAttribute

当前类中每个单元测试方法后，都会执行该方法，用于卸载和清除

ClassCleanupAttribute

当执行完该类所有单元测试之后，执行该方法

AssemblyCleanup

当当前程序集中所有单元测试都执行完后，执行该方法

异常以及超时类Attribute

ExpectedExceptionAttribute

标记当前单元测试应该出现的异常，如果应该出现的指定类型的异常没有出现，则认为这个单元测试失败

TimeoutAttribute

设定当前单元测试的最大执行时间，如果该方法执行的时间超过了该值，则会认为该单元测试未能通过

特殊作用类Attribute

DataSourceAttribute

逐行读取指定数据源中的数据，每行数据会执行当前单元测试方法一次。通过testContextInstance对象上的DataRow索引器属性访问每行上的各列数据。

需要注意的是，以上绝大多数Attribute并不能使用在单元测试中，而是在集成测试中使用

以下附上一段典型的单元测试代码作为展示

using System;
using System.Data;
using System.Reflection;
using System.Text;
using System.Collections.Generic;
using System.Linq;
using ALite.Core.UnitTestSimple;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Moq;

namespace ALite.Core.Tests
{
[TestClass]
public class OrderUnitTest
{
private TestContext _testContextInstance;
public TestContext TestContext
{
get { return _testContextInstance; }
set { _testContextInstance = value; }
}

[TestMethod]
[Description("A normal unit testing for the method 'Submit.'")]
public void TestNormalSubmit()
{
// Mock
var mockPersistence = new Mock<IPersistence>();
mockPersistence.Setup(e => e.Save(It.IsAny<Order>())).Returns(true);

// Arrange
var target = new Order
{
PesistenceHandler = mockPersistence.Object
};
const bool expected = true;

// Action
bool result = target.Submit();

// Assert
Assert.AreEqual(expected, result);
}

[TestMethod]
// 是且只有是抛出DataException类型的异常时才会算通过，即便是子类也会判断为未通过
[ExpectedException(typeof(DataException))]
[Description("A unit testing for the method 'Submit' with a DataException when using the property PersistenceHandler")]
public void TestSubmitWithException()
{
// Mock
var mockPersistence = new Mock<IPersistence>();
mockPersistence.Setup(e => e.Save(It.IsAny<Order>())).Throws(new DataException());

// Arrange
var target = new Order
{
PesistenceHandler = mockPersistence.Object
};
const bool expected = true;

// Action
bool result = target.Submit();

// Assert
Assert.AreEqual(expected, result);
}

[TestMethod]
[Description("举例说明如何测试私有方法和使用TestProperty属性")]
[TestProperty("City", "深圳")]
[TestProperty("Province", "广东")]
[TestCategory("Category1")]
public void TestCountTotalPrice()
{
var method = Util.GetCallingMethod(false, 0);
var attributeType = typeof(TestPropertyAttribute);
var attributes = method.GetCustomAttributes(attributeType, true);

var city = ((TestPropertyAttribute)attributes[0]).Value;
var province = ((TestPropertyAttribute)attributes[1]).Value;

var address = string.Format("{0} {1}", province, city);

// Mock
var mockDeliveryManageHandler = new Mock<IDeliveryManage>();
mockDeliveryManageHandler.Setup(e => e.CountDeliveryFee(It.IsAny<string>())).Returns(10.00m);

// Arrange
var orderDetails1 = new OrderDetail()
{
TotalPrice = 10.00m
};

var orderDetails2 = new OrderDetail()
{
TotalPrice = 20.00m
};

var orderDetails3 = new OrderDetail()
{
TotalPrice = 30.00m
};

var details = new List<OrderDetail> {orderDetails1, orderDetails2, orderDetails3};

var target = new Order()
{
Destination = address,
DeliveryManageHandler = mockDeliveryManageHandler.Object,
OrderDetails = details
};

const decimal expected = 70m;

// Action
// 通过反射测试私有方法，比IDE提供的方式会更灵活一些
var typeTarget = typeof (Order);
var methodTarget = typeTarget.GetMethod("CountTotalPrice", BindingFlags.Instance | BindingFlags.NonPublic);
var objResult = methodTarget.Invoke(target, null);

// Assert
Assert.AreEqual(expected, (decimal)objResult);
}

[DeploymentItem("1.1-ALite.Core.Tests\\1.xml"), TestMethod]
[DataSource("Microsoft.VisualStudio.TestTools.DataSource.XML", "|DataDirectory|\\1.xml", "Address", DataAccessMethod.Sequential)]
[Description("举例说明如何使用DataSourceAttribute属性, 该单元测试会读取数据源中的每一行数据进行测试")]
public void TestCountTotalPriceWithVarious()
{
var province = this._testContextInstance.DataRow["Province"];
var city = this._testContextInstance.DataRow["City"];
var fee = Convert.ToDecimal(this._testContextInstance.DataRow["Fee"]);

var address = string.Format("{0} {1}", province, city);

// Mock
var mockDeliveryManageHandler = new Mock<IDeliveryManage>();
mockDeliveryManageHandler.Setup(e => e.CountDeliveryFee(It.IsAny<string>())).Returns(10.00m);

// Arrange
var orderDetails1 = new OrderDetail()
{
TotalPrice = 10.00m
};

var orderDetails2 = new OrderDetail()
{
TotalPrice = 20.00m
};

var orderDetails3 = new OrderDetail()
{
TotalPrice = 30.00m
};

var details = new List<OrderDetail> { orderDetails1, orderDetails2, orderDetails3 };

var target = new Order()
{
Destination = address,
DeliveryManageHandler = mockDeliveryManageHandler.Object,
OrderDetails = details
};

decimal expected = fee;

// Action
// 通过反射测试私有方法，比IDE提供的方式会更灵活一些
var typeTarget = typeof(Order);
var methodTarget = typeTarget.GetMethod("CountTotalPrice", BindingFlags.Instance | BindingFlags.NonPublic);
var objResult = methodTarget.Invoke(target, null);

// Assert
Assert.AreEqual(expected, (decimal)objResult);
}
}
}

本文链接

My Record Series: (1.3) Windows Phone 7 Application Events

2011-07-06T09:26:00Z

Application_Launching

发生时机
用户从已安装应用列表点击并启动应用，一个应用实例被创建

动作
不要从独立存储中去读取配置信息，那样会降低加载速度；
不要尝试去恢复临时性状态数据（内存变量）；
当一个应用被启动，它会总是被当做一个新的实例展现。（不是接着上次操作）

Application_Activated
发生时机
触发这个需要同时满足两个条件：
1. 用户使用Launcher，Chooser或是启动了另一个应用，导致离开了当前应用；
2. Launcher或Chooser操作完成后返回到应用或Back按键返回到应用。
这个事件不会在应用首次启动时被激活。
动作
应用应允许用户像从未离开这个应用一样继续操作；
临时性数据应该被恢复，但不应尝试从独立存储中读取以避免导致运行变慢的可能性。

Application_Deactivated
发生时机
用户使用Launcher, Chooser或是启动了另一个应用，导致离开了当前应用
但这个事件不会在程序关闭时发生
动作
应该保存所有临时性状态（例如当前应用的会话信息）到State dictionary;保存所有持久化信息到独立存储。
该事件最大允许执行时间为10秒，如果超过10秒还未能执行完成，程序将被关闭而不是进入墓碑化。

Application_Closing
发生时机
使用Back按键退出应用程序的第一页
动作
保存所有持久化信息到独立存储

本文链接

My Record Series: (1.2) Windows Phone 7 Launchers and Choosers

2011-07-05T18:56:00Z

区别：Launcher不会返回调用程序任何信息，例如发送邮件任务；Chooser会返回一定的信息给调用程序，例如相册选择。

Launchers启动器：

EmailComposeTask：启动发送Email的应用程序。

MarketplaceDetailTask：启动Marketplace客户端应用程序，并显示指定应用的详细信息。

MarketplaceHubTask：启动Marketplace客户端应用程序。

MarketplaceReviewTask：启动Marketplace客户端应用程序的审查页面。

MarketplaceSearchTask：启动Marketplace客户端应用程序的搜索页面。

MediaPlayerLauncher：启动MeidaPlayer应用程序。

PhoneCallTask：启动打电话应用程序。

SearchTask：启动搜索应用程序。

SmsComposeTask：启动发短信应用程序。

WebBrowserTask：启动IE。

Choosers选择器：

EmailAddressChooserTask：启动选Email地址界面，选择后返回Email地址。

CameraCaptureTask：启动照相界面，拍照后返回照片图像。

PhoneNumberChooserTask：启动电话号码选择界面，选择后返回电话号码。

PhotoChooserTask：启动图片选择界面，选择后返回图像信息。

SaveEmailAddressTask：启动保存Email地址界面，选择后返回保存是否成功。

SavePhoneNumberTask：启动保存电话号码界面，选择后返回保存是否成功。

本文链接

My Record Series: (1.1) Windows Phone 7.1 Development Environment

2011-06-11T13:57:00Z

Installation & Sequence

1. Visual Studio 2010 Ultimate English Edtion

2. Visutal Studio 2010 Service Package 1 Full Download

3. Expression Studio 4.0 Dreamspark Edtion

4. Blend Service Package 1

5. Windows Phone Developer Tools 7.1 Beta

Notification:

1. You can install all for them in a VM, but the emulator of Windows Phone doesn't support to run in a VM.

2. By default, Windows Phone Developer Tools DOESN'T support other Windows version except Windows 7 and Vista, even if Windows Server 2K8R2.

Modify the element [gencomp7788] in the baseline.dat on the WPDT ISO image: Update the value from 1 to 0.

本文链接

结合测试驱动TDD实施单元测试UnitTest

2011-03-01T17:08:00Z

在之前的文章《单元测试培训系列：（一）单元测试概念以及必要性》中最后一段有提到，单元测试其实是完全为了测试先行，测试驱动准备的，并简单阐述了一下实施的流程，很多朋友对此很感兴趣，希望能更深入了解具体是如何实施的。

隔离，是单元测试中最重要的概念。一个被单元测试的方法，需要与所有依赖项进行隔离。而依赖项包括了环境的依赖项（I/O，网络，数据库，系统时间等）以及外部类和方法的依赖。因此，隔离性保障了单元测试是最小粒度的测试。

但隔离也导致了单元测试的局限性，主要是以下两个方面：

1. 通过单元测试是不能检测到一个方法修改后对系统的影响范围的。

单元测试因为隔离了对其他方法的依赖，因此当一个方法因为重构或者修改BUG等原因进行了改变时，运行已有的单元测试只能检测到这个被修改的方法本身是否依然符合以前预期的目标；而对修改这个方法对整个系统有任何影响，是完全无法通过运行单元测试得知的！！

很多朋友一直错把集成测试和单元测试混为一谈，认为单元测试能够检测到一个方法改变后对整个系统哪些部分造成了影响，这种想法很显然是错误的：因为单元测试的每个测试方法都把被测试的方法和其他方法、外部环境隔离开来，每一个被测试的方法都不依赖其他方法的具体实现，因此，即便其他类或方法的实现发生了改变，只要接口依然保持原样，对当前的单元测试是都不会产生任何影响的！！

2. 单元测试对于需求变更基本没有太大作用。

需求发生变更，首先要改变的就是单元测试！因为单元测试的关注点是每个方法的进出项（输入值和输出值）是否满足期望值。当发生需求变更时，意味着相关方法的预期值发生改变，此前相关的单元测试不再具有价值，需要重新编写。

因为以上两个原因，对一个已有系统的代码追加单元测试的价值也变得非常鸡肋了。对于一个已有系统追加单元测试之后，单元测试唯一能在某个方法的内部实现进行重构的时候起到作用（例如修改BUG和算法优化，并且是在不修改当前调用关系以及相关接口的前提下）

基于测试先行来使用单元测试

说了这么多局限性，估计很打击大家积极性，难道单元测试就那么一无是处么？非也，而是单元测试的使用场景没对。

测试先行还是测试驱动也好，都是目标导向方法论的具体实践，其目的都是在编写代码之前先行确定好要编写代码的目标以及校验方式。而再来看单元测试，单元测试只关注一个单独方法本身的功能以及这个方法的进出项是否满足期望值。这根本上就是和测试先行的目标是完全吻合的。可以说单元测试是测试先行的具体实施办法。

有了这个基调，我们再来看如何把单元测试按照测试先行的指导来进行实施，因为该篇文章的关注点还是单元测试，就不过多探讨如何实施测试先行或者测试驱动。

我们直接从拿到一个具体的业务功能模块开始。

一、设计简要的类图以及类之间关系

我们首先简要的为该模块设计出基本的类图和类之间的关系（虽然有些敏捷方法对测试先行的要求是不做设计，只做测试用例，然后再编写测试代码和实现代码，但在这里个人还是按照先设计功能的类结构方式）

在这个阶段，基本只需要定义好几个类，而类里面的成员则没有必要在一开始就全部设计出来。（推荐使用Visual Studio里的项目选项View Class Diagram进行代码和类设计的同步进行）
来看下面这个例子：一个订单系统，订单明细里面的每条订单的产品分为服装和数码产品类，而服装的价格来源是Vancl，数码产品的价格来源是Newegg. 首先这个订单系统需要一个订单统计总价格的功能。

如上图所示，定义了主要的类以及彼此之间的关系, 除了一些数据属性外，还没有定义这几个类的方法。
ProductOrder类，即定单类，需要实现方法Count，包含一个IList<BaseOrderDetail>类型的属性OrderDetails。

BaseOrderDetail类，抽象类，包含ProductID和Amount属性以及一个IPriceProvide类型的属性PriceProvider，以及一个Count方法，即每条明细合计自己的总价。

ClothingOrderDetail类，BaseOrderDetail的子类，即服装类的订单明细，该类的PriceProvider属性应该为VanclProvider类的实例。

DigialOrderDetail类，BaseOrderDetail的子类，即数码类的订单明细，该类的PriceProvider属性应该为NeweggProvider类的实例。

IPriceProvide接口，该接口定义提供了从第三方获取产品价格的查询方法QueryPriceByProductID。

VanclProvider类，实现了IPriceProvide接口，提供Vancl的产品价格查询。

NeweggProvider类，实现了IPriceProvide接口，提供Newegg的产品价格查询。

二、为某一个类上的某一个公开方法编写单元测试

当类以及类之间关系设计好之后，就开始根据业务功能的需要，逐步设计类的成员以及方法以实现这个类的功能。而在设计一个类的方法时，则是根据业务需求的要求来设计的，因此在编写一个类中的公开方法时，对这个类需要达成什么样的效果，应该是非常明确的。在明确了目标之后，其实编写单元测试就已经可以实现了，尽管现在实现代码还根本不存在。根据上面的例子，我们首先来编写ProductOrder类的Count方法的单元测试，此时，Count方法是没有真正实现的，甚至Count方法都还不存在（在单元测试代码中使用dynamitic关键字调用不存在的Count方法）。

ProductOrder类的Count方法，其实是统计所有单据中包含的所有货物的价格，因此可以分析得知Count方法依赖于BaseOrderDetail类的Count方法，并且属性OrderDetails会包含多个BaseOrderDetail类，这意味着在编写单元测试时，我们需要把这些BaseOrderDetail类都使用Mock对象代替。

在这个单元测试代码中，我们因为估计到实现Count方法需要依赖于OrderDetails属性，并合计里面所有BaseOrderDetail对象的价格，而BaseOrderDetail的价格是通过BaseOrderDetail.Count()方法获得的。我们只是测试ProductOrder的Count()方法，因此不需要再深入思考BaseOrderDetail.Count是如何实现的，只需要对BaseOrderDetail.Count()方法进行Mock即可。

因此在这段代码中，添加了三个Mock的BaseOrderDetail对象，并分别设置他们的Count()方法返回值，最后把它们都加入到ProductOrder的OrdeDetails属性中。到此，这个单元测试就写完了，但其实此时，我们的Count方法还根本没实现。所以运行单元测试会抛出异常。

二、编写方法的真正实现逻辑

那么，接下来，我们来实现这个方法的实际逻辑。

Unit Test for Count

现在再运行之前的单元测试，会发现该单元测试已经顺利通过。大家是否看明白：单元测试只需要知道对被测试方法的期望值以及该方法可能依赖的项即可编写，无论这些方法是否已经真的实现。甚至可能的依赖项都是可以不用一开始编写的，而可以等到实现代码时发现需要调用其他方法时，再修改相应的单元测试代码进行隔离。

在这里再多写一个例子，方便大家加深认识。这次对BaseOrderDetail上的Count方法编写单元测试。

Unit Test for Count

这段代码是最简单的单元测试框架，如果执行肯定会因为Count方法还未实现而抛出异常。接下来我们编写Count方法的实现，

Unit Test for Count

可以看到BaseOrderDetail中的Count方法依赖于自身的属性PriceProvider，而该属性本应该是根据订单的类型指定对应的VanclProvder类的实例。如果此时，我们再运行单元测试，必然会引发空引用异常，原因是此时的PriceProvider属性并没有赋值。（在实际运行的代码中可以使用例如Autofac或者Unity之类的IOC容器实现初始化）
因此，我们需要在单元测试中添加Mock对象，来隔离对外部对象的依赖。修改后的单元测试代码如下：

Unit Test for Count

至此，两个单元测试都能顺利的通过验证。

三、当需求发生改变时，修改单元测试以及实现代码

我们假定我们的开发已经进入到一定阶段（已经有了两个类和方法的实现，并已经稳定），这时候需求发生了变更，我们来看下此时应该如何进行操作。

第一种情况，需求变更为，如果订单明细是ClothingOrderDetail类型时，Count方法需要在价格乘以数量之后增加额外的10元邮费。这种情况，其实只需要在ClothingOrderDetail类中重载BaseOrderDetail的Count方法即可，因此编写新的单元测试和方法实现即可。

从这里可以注意到一点单元测试的特性：虽然我们修改了BaseOrderDetail的需求和实现，但ProductOrder中Count方法的单元测试并无法检测到这种变化，甚至BaseOrderDetail的Count方法修改后会引发异常，也无法通过单元测试得知BaseOrderDetail中Count方法产生的异常会到只ProductOrder中的Count方法也会发生异常。这是单元测试的局限性。

第二种情况，需求变更为，如果订单的总额度超过5000，可以享受减免100的优惠。此时，可以先修改ProductOrder.Count方法的单元测试中的期望值为8648.55，再修改实际的代码实现如下：

Unit Test for Count

可以看到其实这是在实现代码中添加了一个条件判断分支，我们也许需要为条件分支再单独写一个单元测试（略）。

第三种情况，即需求发生重大变化，导致代码结构发生严重变化，那么基本之前的所有单元测试和实现代码都已经作废，甚至编译无法通过。

其实单元测试在开发完成后能起到的作用，仅限于这种场景，对一个方法的实现进行优化，例如VanclProvider类的QueryPriceByProductID方法由以前从数据库查询，改为先从本地缓存中读取，若缓存不存在才从数据库中读取，因为期望值并为发生改变，只是修改了这个方法的实现方式，因此在修改之后依然可以通过单元测试进行验收是否修改正确，即新的修改是否依然符合早期的需求（期望值没发生改变，则单元测试不发生改变）。

误区：

很多朋友一直把单元测试和集成测试搞混，因此一直有个误区：

认为只要对所有方法都编写了单元测试，在将来代码发生变化之后，可以通过运行单元测试快速的通过计算机校验得到所有受当前代码变化影响的用例以及影响范围。实际上，如果你仔细看到这里，你应该已经知道，这其实是不可能的。

单元测试的隔离性，导致了代码的影响不会传递：一个方法的实现导致了异常，并不会影响到其他调用过它的方法在原有的单元测试中顺利通过（Mock方法代替了实际方法的执行）。

总结：

通过以上这些例子，描述了如何结合测试先行的思想去做单元测试，核心的一点即是：目标先行，每实现一个方法之前先考虑这个方法要达到的目标是什么，再编写这个目标的检测手段（单元测试），最终去实现这个方法，并通过之前设想和编写的检测手段去验证这个实现是否已经达到预期的目标。

另一方面，这个过程也强烈的反应出了，单元测试作为测试的一种手段，其实在代码实现后，即维护阶段能起到的作用非常的小：

当需求发生变化时，需求的预期值必然发生变化，意味着单元测试需要被修改或重新编写。此时，原有的单元测试已经起不到事后检查的作用了。

只有在需求未发生改变时，对现有代码进行不涉及结构改变的优化时，用于修改后的代码是否依然满足之前的需求预期。但实际应用中，这种场景少之又少。

本文链接

架构评审表(Architecture & Design Review Check List)

2011-01-23T11:33:00Z

性能和可扩展性(Performance and Scalability)
可靠性(Reliability)
可用性(Availability)
可管理性(Manageability)

1. 性能和可扩展性(Performance and Scalability)

部署与基础架构 Deployment and Infrastructure
- 合理的使用分布式架构，只在必要时才引入分布式
  Use distributed architectures appropriately. Do not introduce distribution unnecessarily.
- 谨慎地选择合适的分布式通讯的机制
  Carefully select appropriate distributed communication mechanisms.
- 把频繁交互的组件都尽可能的放在相同的边界内，或者尽可能的靠近（就近原则）
  Locate components that interact frequently within the same boundary or as close to each other as possible.
- 在设计中，把基础架构的限制考虑在内
  Take infrastructure restrictions into account in your design.
- 考虑网络带宽限制
  Consider network bandwidth restrictions.
- 明确资源限制
  Identify resource restrictions.
- 确保你的设计不会制约纵向扩展
  Ensure your design does not prevent you from scaling up.
- 使用支持横向扩展和逻辑分层的设计，避免无意中引入的依附关系，使能够支持负载均衡
  Ensure your design does not prevent you from scaling out and it uses logical layers, does not unwittingly introduce affinity, and supports load balancing.
耦合和内聚 Coupling and Cohesion
- 确保你的设计是松散耦合的
  Ensure your design is loosely coupled.
- 在你的设计中体现适度的内聚，将相关的实体如类和方法分组
  Exhibit appropriate degrees of cohesion in your design and group together logically related entities, such as classes and methods.
- 有限制的使用后期绑定（如反射等），只在必要时适当地使用后期绑定
  Restrict use of late binding and only use late binding where it is necessary and appropriate.
通讯 Communication
- 避免接口过度会话（即避免太小粒度的通讯接口）
  Interfaces do not enforce chatty communication.
- 确保你的应用程序只在必要的地方进行远程调用；通过客户端验证、客户端缓存以及批量作业最小化影响
  Ensure your application only makes remote calls where necessary. Impact is minimized by client-side validation, client-side caching, and batching of work.
- 优化远程数据交换（例如数据压缩，序列化等）
  Optimize remote data exchange.
- 选择适当的通讯加密机制
  Choose appropriate secure communication mechanisms.
- 使用消息队列解耦你系统的各个组件
  Use message queues to decouple component parts of your system.
- 使用消息队列,“射后不理”方式(fire-and forget)以及异步方法调用等，降低Long-running调用的影响
  Mitigate the impact of long-running calls by using message queues, "fire-and forget" approaches, and asynchronous method calls.
- 在应用程序域更合适的情况下不要使用进程
  Do not use processes where application domains are more appropriate.
并发 Concurrency
- 不要在你的程序里为每一次请求创建线程，使用CLR提供的和Win32提供的线程池代替
  In your application do not create threads on a per-request basis, and use the common language runtime (CLR) thread pool and Win32 thread pool instead.
- 只把那些必须线程安全处理的类型置为线程安全
  Only types that need to be thread-safe are made thread-safe.
- 谨慎考虑锁的粒度
  Carefully consider lock granularity.
- 确保你的程序获取资源和锁尽可能的迟，释放他们尽可能的早，从而减少冲突可能
  Ensure your application acquires shared resources and locks late and releases them early to reduce contention.
- 选择恰当的同步基元
  Choose appropriate synchronization primitives.
- 选择一个恰当的事务隔离级别
  Choose an appropriate transaction isolation level.
- 确保让异步执行I/O密集任务，但对于CPU密集任务则就无需异步执行
  Ensure your application uses asynchronous execution for I/O bound tasks and not for CPU bound tasks.
资源管理 Resource Management

确保你的设计支持并高效的利用各种“池技术”
Ensure your design supports and makes effective use of pooling.
确保你的程序对资源的获取和释放遵循尽量晚获取，即早释放
Ensure your application acquires resources late and releases them early.

缓存 Caching

对那些代价大的数据（如数据获取，复杂运算以及呈现）使用缓存
Use caching for data that is expensive to retrieve, compute, and render.
缓存适当的数据，如静态页面，输出数据的某些特定项，存储过程的参数以及查询结果等
Cache appropriate data such as relatively static Web pages, specific items of output data, stored procedure parameters, and query results.
不要对那些不稳定的数据使用缓存
Do not use caching for data that is too volatile.
选择一个合理的缓存位置
Select an appropriate cache location.
选择一个合理的缓存过期策略
Select an appropriate cache expiration policy.

状态管理 State Management

你的设计应该尽可能的使用无状态的组件，除非你已经认真考虑对于可扩展性的负面影响后才决定使用状态化组件
Your design favors stateless components. Or, you considered the negative impact on scalability if you decided to use stateful components.
如果使用.NET Remoting并且需要支持负载均衡，你需要使用Single Call的服务器端激活模式(SAO)
If you use Microsoft® .NET Framework remoting and need to support load balancing, you use single call server-activated objects (SAO).
如果你使用WebServices, 你也需要使用一种基于消息的无状态模式
If you use Web services, you also use a message-based stateless programming model.
如果你使用Enterprise Services, 也需要使用无状态的组件使其能够放入对象池中
If you use Enterprise Services, also use stateless components to facilitate object pooling.
那些需要被放到状态存储中的的对象必须可序列化
Objects that you want to store in state stores support serialization.
考虑ViewState对性能的影响
Consider the performance impact of view state.
根据Session的并发量以及每用户使用的Session数据量来选择一个合适的Session状态存储模式
Use statistics relating to the number of concurrent sessions and average session data per user to help choose an appropriate session state store.

数据结构与算法 Data Structure and Algorithms

确保你的设计使用了合适的数据结构
Ensure your design uses appropriate data structures.
只要在万不得已的情况下使用自定义集合
Use custom collections only where absolutely necessary.
如果你需要实现自己的集合请实现IEnumerable接口
Extend the IEnumerable interface for your custom collections.

数据访问 Data Access

在各层之间传递数据时使用最合适的数据格式，认真的考虑性能影响
Pass data across the layers by using the most appropriate data format. Carefully consider the performance implications.
通过Paremters（参数集合，.NET调用SQL的API）的形式调用参数过程进行数据访问
Use stored procedures with the Parameters collection for data access.
只处理和传递那些你真正需要的数据
Only process the data that is required.
为那些大数据量的查询结果集提供合适的数据分页解决方案
Where appropriate, provide data paging solutions for large result sets.
对那些涉及多个资源管理器的事务，在事务上下文需要跨越多个部件时，可以采用企业服务的声明式事务来处理
Use Enterprise Services declarative transactions for transactions that span multiple resource managers or where you need to flow transaction context across components.
如果你要控制二进制大对象(BLOBs)，使用恰当的chunking技术，不要重复的移动相同的BLOB
If you manipulate binary large objects (BLOBs), use appropriate chunking techniques, and do not repeatedly move the same BLOB.
把重复的数据访问代码集中放入Helper类中
Consolidate repeated data access code into helper classes.

异常处理 Exception Handling

不要使用异常去控制正常的程序逻辑流程
Do not use exceptions to control regular application flow.
使用明确的异常处理边界（防止异常信息扩散）
Use well-defined exception handling boundaries.
结构化的异常处理是更好的错误处理机制，不要使用错误代码来反馈
Structured exception handling is the preferred error handling mechanism. Do not rely on error codes.
只为特定的原因，并在真的需要捕捉的时候去捕捉异常
Only catch exceptions for a specific reason and when it is required.

类设计的考虑 Class Design Considerations

类拥有它们操作的数据
Classes own the data that they act upon.
只在必要时使用显性接口. 当你有一些公有的功能穿插于多个类时，使用显性接口实现多态以及版本化
Do not use explicit interfaces unnecessarily. Use explicit interfaces for versioning and for polymorphism where you have common functionality across multiple classes.
除非真的需要，否则不要类里包含虚方法
Classes do not contain virtual methods when they are not needed.
使用重载方法比使用可变参数方法更好
Prefer overloaded methods to methods that take variable parameters.

2. 可靠性 (Reliability)

设计方面 Designing for Reliability

参照Windows Server 2003的应用程序开发规范
Follow the Application Specification for Microsoft Windows Server 2003 http://www.microsoft.com/windowsserver2003/partners/isvs/appspec.mspx
把可靠性需求列入开发规范
Put Reliability requirements into the specification.
良好的基础架构的使用
Use of good architectural infrastructure
把管理信息也放入应用程序中
Built Management Information into the application
使用冗余提高可靠性
Use Redundancy for Reliability
使用内置的应用程序健康状态检查
Use Built-In Application health checks
使用可靠的错误处理
Use Consistent Error Handling

测试方面 Testing for Reliability

使用组件压力测试
Use Component Stress Testing
使用集成压力测试
Use Integration Stress Testing
使用实际环境测试
Use Real-World Testing
使用随机破坏测试
Use Random Destruction Testing

3. 可用性 (Availability)

设计方面 Designing for Availability

通过使用群集减少计划外的宕机时间
Reduce Unplanned Downtime with Clustering
使用网络负载均衡
Use Network Load Balancing
使用RAID磁盘阵列进行数据存储
Use Raid for Data Stores
减少计划内的宕机时间
Reduce Planned Downtime
隔离危险应用
Isolate Mission Critical Applications
使用队列
Use Queuing
使用分布式文件系统（DFS）
Use Distributed Files System (DFS)

测试方面 Testing for Availability

变更控制过程测试
Test the Change Control Process
灾难性故障测试
Test Catastrophic Failure
测试故障转移技术
Test the Failover Technologies
测试监控技术
Test the Monitoring Technology
测试Help Desk过程
Test the Help Desk Procedures
资源冲突测试
Test for Resource Conflicts

4. 可管理性 (Manageability)

设计方面 Designing for Manageability

在应用程序中使用企业库的Logging框架以提高可管理性
Use Enterprise Library Logging Framework in Application to support Manageability
使用WMI
Use Windows Management Instrumentation
使用SMS服务器
Use Systems Management Server
使用性能监视
Use Performance Monitor
使用系统准备工具 (Sysprep. Exe)
Use System Preparation Tool
使用SNMP网络监控协议
Uses SNMP
使用HTTP监控工具
Use HTTP Monitoring Tool
使用MS Web兼容性分析工具
Use MS Web Capacity Analysis Tool

测试方面 Testing for Manageability

测试WMI
Test WMI
测试群集配置
Test Cluster Configuration
测试网络负载均衡
Test Network load Balancing
测试应用程序同步
Test Application Synchronization

本文链接

单元测试培训系列：（三）可测试性（Testability）与重构Refactoring

2011-01-09T09:23:00Z

在单元测试培训系列：（一）单元测试概念以及必要性中，我们已经说过单元测试的定义是什么，里面有提到一个很重要的概念：隔离！是的，没有隔离就没有可测试性，也就没有单元测试。

可测试性Testability

下面我们具体解释下什么叫做可测试性Testability:
让你的代码变的更加松耦合(Loosely coupled)，让类与类之间的关联性降低，降低到可以个别独立存在，如此一来便可在彼此互不影响之下完成个别的单元测试，而这些类又能组合成一个有用的应用程式。

因为单元测试要尽可能的隔离与当前方法逻辑没有关系的方法以及外部资源（I/O文件，配置文件，数据库，网络以及静态变量等），即要求每段代码在不依赖其他额外方法以及外部资源的情况下依然可以正确执行！

这么说也许你无法理解也很难想象应该如何做到，那么我们下来举个例子说明。

Code Sample

以上代码中，可以看到Testability类的ComplexCompute方法中依赖于CalcServiceWrapper类，并调用了该类的Multiply和Divide方法，最终完成了自身的功能。但这个代码就不具有很好的可测试性，因为ComplexCompute无法离开CalcServiceWrapper类而正确编译执行。那么如何重构这段代码使它可以解耦从而具有良好的可测试性呢？依赖倒置(Dependency Inversion)可以做到！

依赖倒置

依赖倒置是一种设计模式，具体的概念大家可以参见：向依赖关系宣战——依赖倒置、控制反转和依赖注入辨析, 在这里就不深入的去阐述依赖注入是怎么回事了。

其实，如果你已经仔细看完那篇文章或者你已经知晓那些知识，那么其实所谓的解耦重构也就很简单了。

依赖注入，有三种实现方式：属性注入，构造函数注入，方法参数注入；在实际项目中，属性注入是最常见的方式，我们下面就来用这种方式来对之前的代码进行解耦重构：

Code Sample

如上代码中可以看到，把ComplexCompute方法中用到的CalcServiceWrapper类以及实例化的代码去掉，而增加一个类型为ICalcService（其实也可以是CalcServiceWrapper）的公开属性，在ComplexCompute方法中通过调用该属性来实现调用逻辑。这时候我们再来看，有没有发现，CalcService.Multiply方法和CalcService.Divide方法，无论CalcService是否被赋值，被赋予任何对象并不会影响当前方法的编译通过。换句话说：ComplexCompute方法不再依赖于CalcServiceWrapper类型是否实现以及如何实现。

可能说到这里，你依然无法理解，代码被重构后解耦了，但这跟可测试性又有多大的关系呢？很遗憾的是目前因为有个很重要的概念还没能介绍，在这里只能简单的提及，那就是Mock Object，将会在后面的章节详细介绍，这里先简单带过。所谓Mock Object其实就是个假对象，但它只是模拟一个对象中某个/些方法，输入某些参数，返回一个预先设定的值，不用真的去执行代码。这样在做单元测试的时候，我们可以给Testability类实例的CalcService属性设置一个Mock Object, 然后在我们测试其中的ComplexCompute方法的时候，我们可以保证里面的用到的CalcService方法都按照我们期望并设定的方式执行（返回的值），从而实现：我们测试Testability类中的ComplexCompute方法的时候，不会再担心CalcServiceWraper类的实现是否存在错误，或者发生什么问题，因为在ComlexCompute中执行的是Mock Object，而不是真正的CalcServiceWraper对象。我们的单元测试于是就只是测试ComplexCompute方法，不再涉及其他方法！

非可测试性场景Untestable Scene

上一段提到的是依赖倒置是最正规的符合Testability的代码模式，但实际应用中，我们可能无法做到完全很好的执行，但有几种场景我们是必须要特别注意并避免的。

1. 静态变量

静态变量是非常不符合Testability要求的（但在处理遗留系统Legacy System时会有特别的用处，后文会提及）。

首先来看静态变量，因为静态变量是全局性的，而且是保持有状态的。在单元测试培训系列：（一）单元测试概念以及必要性中，我们有说过，单元测试是测试的最小单位，必须可信任的，可重复执行的。因此，若使用静态变量，就会导致破坏单元测试的可重复执行性，并且可能干扰到别的单元测试方法。

例如：在方法A中改变了全局静态变量StaticVariableA的值，而在方法B中又要去尝试读取这个静态变量的值，那么在单元测试执行的过程中，若执行方法A和方法B的单元测试方法顺序不同，或执行多次很可能每次结果都会不同，这样明显会导致我们的单元测试结果不再可信。因此，我们应该尽量避免静态变量的使用。

2. 静态方法

静态方法的可测试性不强的原因倒不是因为静态方法自身有什么太大的问题，而是在编写单元测试的过程中受制于工具框架的限制：目前的开源Mocking Framework中都不支持对静态方法进行模拟，若大量使用静态方法，会在编写单元测试的时候遇到无法解耦的问题。当然利用一些商业Mocking Framework，如TypeMock，Moles等可以规避这个问题。

除了静态方法外，因为同样的开源Mocking Framework项目的限制，sealed类也是可测试性很差的代码。具体原因，我们放到后面的Mock Object章节一起介绍。

3. 直接依赖外部环境

一般来说，单元测试是要求代码尽可能不直接依赖于I/O文件接口，数据库，网络环境甚至系统环境（如时间等），但实际上一个项目总会有一部分代码无可避免的需要去访问这些外部资源，但我们可以尽量的控制这些代码集中在较小的范围内，并通过提取接口的方式使其他代码和这些直接访问外部资源的代码之间解耦。

因此，泛滥的在代码中随意使用访问外部资源的代码是非常Untestable的设计，例如：在程序中到处都是访问数据库的代码，DataContext出现在每层代码中；到处充满依赖于ASP.NET或者WCF环境的代码（HttpContext, HttpRequest等）。

我们没办法实现对边界代码的单元测试，只能通过集成测试来检验，例如对数据库访问层代码的测试；对网络访问层代码的测试等。但我们必须尽可能的防止这些边界代码的扩散，要尽可能的使他们被隔离起来。这个问题因为涉及面很广，暂不展开说明，在接下来的篇幅中会专门针对Entity Framework和ASP.NET MVC的Testability进行优化分析。

Testability and Entity Framework 4.0

Unit Testing ASP.NET MVC

本文链接

单元测试培训系列：（一）单元测试概念以及必要性

2011-01-02T15:05:00Z

说起单元测试，多数同学应该都知道或听过，可能不少同学认为自己也写过，甚至觉得单元测试很简单有什么好培训的？其实这个事情还真没想象的那么简单！我基本可以比较负责任的说，你若没深入对单元测试做过研究，不知道Mock对象为何物的话，那么可能你以前写过的单元测试压根就不是单元测试。

单元测试是什么？

这个问题其实并不太容易一两句话说得特别清楚。先借用下百度百科的定义：

单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

从以上这句定义我们可以看到，两个提取到到两个非常关键的字：最小粒度、隔离

单元测试是测试的最小单位，必须可信任的，可重复执行的。
如果测试的范围轻易的就会扩展到其他类或同类的其他方法，那就不再是最小单位，也就不是单元测试了！
例如：
类A中的方法CallMethod中调用了类B中的方法DoMethod，如果在编写测试的时候不把B类中的DoMethod隔离出来，造成单元测试CallMethod方法时，实际实行了DoMethod方法，那么这个测试方法不能算作是单元测试。（如何隔离会在后文详解）

单元测试的目的是什么？

有人曾给我一段非常简单的代码片段：一个方法，里面只是调用若干个其他方法，甚至也都没有任何返回值，然后问我这种代码写单元测试有任何价值？！完全是浪费体力！！

    public class ClassA
    {
        public void CallMethod()
        {
            DoSomethingForYou();
            DoSomethingForThem();
            DoSomethingForMe();
        }
    }

其实提出这个疑问主要有两个原因导致：未能理解单元测试的目的是什么以及这段代码的可测试性并不高。（可测试性以及如何提高将在后面章节介绍）

单元测试的目的是用来确保程式的逻辑如你预期的方式执行，而并不是用来验证是否符合客户的需求的！通过单元测试来建立一道坚实的保障，防止代码在日后的修改中不会被破坏掉。

是不是很失望？单元测试并不是用来验证代码是否符合需求的。
事实上，单元测试是白盒测试的一种，而且需要开发人员来完成，最好是谁开发的代码就该谁来编写单元测试代码，因为代码的编写者最熟悉该段代码的目的，进而编写出验证该目的是否达到的单元测试代码。
单元测试并不能用来代替其他测试手段，不过是实践过程中确实会很有效的帮助开发人员自查代码，进而发现一些潜在的BUG。但这只是一个额外的收获，若不是采用TDD那样的测试先行开发方式，那么单元测试的根本目的不是用于也无法检验当前代码是否存在BUG的！

上面有说到单元测试最好是由开发人员自己来编写，用于验证该段代码是否符合开发者开发的预期要求。这里可能会有个疑问，既然开发者自己已经很清楚自己想要结果是什么，直接运行一遍代码实际跑一次，通过断点调试不是就可以很方便的验证了嘛？再通过编写代码的形式，甚至比开发这个功能本身更多的代码，去验证这个方法是否符合编写的目的，不是很傻很笨很累的办法么？

也许通过一个大家经常会碰到的实际场景能更好的说明：

一个项目开始，项目经理把需求拆解为若干个模块分发给不同的开发人员去完成。这样每个人可能只熟悉自己的那部分代码。当项目某个阶段开发完成并上线后，可能部分开发人员会离开项目进入别的新项目，留下个别人员继续维护；或者项目下阶段开发新进一大批人员并不熟悉当前项目；当然最常见的是，在修改BUG阶段是无法完全做到谁产生的BUG就安排谁去修改。
那么这时候就会出现一种常见的情况：因为对当前代码要满足的各种目的不熟悉，在修改一个模块或者BUG的时候把原有正确的功能也影响到了！更要命的是，谁也不知道这个BUG出现了，等待测试人员需要去重新发现一遍。

于是项目经理会发现，每次只要做了代码修改，无论是重构还是功能新增修改，还是修改了BUG，都无法知道当前代码的健壮性，以前编写的东西是否依然正确可用？

然而如果这个项目在一开始就编写了单元测试的话，我们可以通过方便的自动化单元测试框架运行所有的单元测试，进而检查在此次修改前的所有被单元测试所覆盖的代码是否依然正常运行（符合以前编写的单元测试期望，如果验证通过，则认为原有代码未受到影响）

由上我们可以看出，单元测试虽然增加了相当大的开发工作量，但对于一个长期不断改进和维护的项目而言，单元测试反而是消减整体成本的一个有效手段，它能及时而准确的发现在代码修改之后，原来对代码要求的功能是否都依然正确满足。

但这里有个严重缺陷：单元测试无法检测到某个方法修改后是否对其他方法造成了影响，只能检测到被修改的方法本身的原有目的是否被影响（这个将在下面的与集成测试的区别中详解）

也因此，个人觉得单元测试最适合的场景是基于TDD开发。若需求发生改变，修改了一个方法，而多数情况下也会去修改单元测试代码，因为预期也发生了改变，这个时候又不能检测到对其他代码的影响，这时单元测试意义确实不大。

单元测试与集成测试的区别是什么？

多数人其实一直不能很好的区分集成测试和单元测试，甚至不少人一直理解的单元测试只能算是集成测试，但其实两者的概念是完全不同的。
单元测试测试的对象是每一个独立的方法，而且尽可能的隔离方法和其他方法以及其他外界依赖项；

基层测试的测试对象是被单元测试检测后的方法与方法之间的调用关系，以及调用执行过程是否符合预期。

针对项目的一部份或全部进行测试，可以跨越不同的类别与方法，并可直接存取的外部资源。例如: File I/O, 数据库操作, 网络连接, …
通常做集成测试都会需要先设置(Configure)测试所需的环境，测试完毕后通常要清除测试所产生的残留资料，以利下次测试或避免影响其他整合测试的结果。

ClassInitialize Attribute
ClassCleanup Attribute
TestInitialize Attribute
TestCleanup Attribute
以上这些属性常用于集成测试，不能出现在单元测试中。

单元测试的三大基本要素（Trustworthiness/Maintainability/Readability)

信任你的测试代码结果
- 你是否能信任你的测试结果？
- 当它通过，我们有信心说被测试代码一定工作。
- 当它失败，它一定证明被测试代码是错误的。
- 如果你不断的对测试结果失去信心，那么你也不会继续坚持撰写单元测试。有
- 许多人搞不清楚单元测试与集成测试的差别，以致于感觉自己写的单元测试过于薄弱而不相信测试的结果。
- 如果你因为某些原因导致测试失败，直接去改Code或直接去改Test Code都不是好事，你的首要目的是要能找出测试失败发生的主因，而非只是看错误这件事，这样你才能信任你的测试程式。
测试代码的可维护性
- 是否能够持续的维护你的测试程式？
- 如何有效的降低维护测试程式的成本？
  PS:透过一些Testable Design Pattern 可以有效提升可维护性。例如: Repository Pattern, Service Pattern……
测试代码的可读性
- 你的测试程式的命名是否易于理解?
- 当你测试失败时是否能从测试失败的测试方法(TestMethod)明确看出实际失败的原因？
- 当读取测试数据的人看不懂你的测试，人们就不会执行这些测试、也不会去维护这些测试，久而久之就会越来越恶化。
Test Driven Development & Unit Test
      写在本文最后，其实我一直觉得单元测试其实是为了TDD开发模式而诞生的，在这种开发模式下使用单元测试完全是非常顺畅的：
      1、根据软件需求文档拆解软件功能，并设计出功能模块划分；
      2、根据需要的功能模块设计出单元测试场景用例，因为此时可以很清晰的知道能够提供什么样的数据，以及需要达到什么样的功能，这对设计单元测试用例已经完全足够了；
      3、编写单元测试代码，这个时候可以专注于检验这个方法的是否满足设计的要求，此时甚至实际的代码还根本没开发，而.NET 4.0的Dynamic关键字在这里可以得到充分的发挥：调用那些根本都还不存在的方法，却不会导致编译无法通过。
      4、若在编写单元测试过程中，可以预期当前这个方法若需要调用一些其他类或方法的支持，可以通过编写Mock Object来模拟，同样也是无需实现真正的代码，只需要有基本的代码框架或者接口即可。
      5、在为这个方法编写好单元测试代码之后，就可以开始编写实际的代码实现了，因为在之前为了满足Testability的需要，代码已经是基于依赖倒置模式的了，无需再担心其他需要调用的类或方法是否已经实现或正确实现。在编写好本方法的实现之后就可以通过运行之前的单元测试进行验收了。
      可以看到，若按照以上这种方式进行开发，首先代码的耦合性是非常低的，其次代码的质量也是很高的，最后还会因为代码之间的耦合度低从而降低在开发过程中，相互制约进度相互影响的可能性。在追查BUG的时候也很有优势：很容易查到BUG是否蔓延。
      反之，对一个Legacy System进行重构使之Testable，再编写单元测试其实工作量不小，实际的收益也不会特别大。

单元测试的基本概念以及价值就基本讲完，下篇文章将开始介绍Visual Studio 2010中的单元测试工具与环境。

本文链接

博客园_風語·深蓝

8天学通MongoDB（实际操作版）——第一天 基础入门

构建Ubuntu Server试验环境

单元测试培训系列：（二）单元测试与Visual Studio

My Record Series: (1.3) Windows Phone 7 Application Events

My Record Series: (1.2) Windows Phone 7 Launchers and Choosers

My Record Series: (1.1) Windows Phone 7.1 Development Environment

结合测试驱动TDD实施单元测试UnitTest

架构评审表(Architecture & Design Review Check List)

单元测试培训系列：（三）可测试性（Testability）与重构Refactoring

单元测试培训系列：（一）单元测试概念以及必要性

8天学通MongoDB（实际操作版）——第一天基础入门