聊聊iOS开发中的单元测试 - 简书
下载简书移动应用
写了20031字，被81人关注，获得了82个喜欢
聊聊iOS开发中的单元测试
看到文章标题的时候，你也许会问，测试不是测试妹子干的事吗？的确，测试妹子能帮助我们测试出软件的很多问题（不符合业务的问题）,但是代码的测试还得靠我们自己啊。团队Leader在开会时一直强调要打造一支不依靠测试团队的团队，因此，代码自测也变成了一个项目重要的一环。是的，今天我要聊的就是我们程序员对自己代码的测试，而不是测试妹子的测试。在iOS开发中我们用单元测试来保证我们的代码可靠性，什么是单元测试，请看在维基百科上的解释：
在计算机编程中，单元测试（英语：Unit Testing）又称为模块测试, 是针对程序模块的最小单位来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。
有了单元测试以后，我们就没必要为了测试某个小模块去编译我们的程序，然后去等待模拟器启动然后到你需要验证的模块去。这样做也是可以的啦！可是，你的项目很大，编译等老半天，你的电脑没那么快，那就够你等的了。我还记得我工作的第一个公司，给我用的是一个性能堪忧的Mac mini，每次修改代码后Command + R后都得等上一分多，简直不能忍受啊！是的，我没能忍受，没过多久我就离职了。扯淡这么半天，就是为了说明单元测试能节约我们的时间，提高开发效率，对于项目越大的效果越明显。
XCode4.x时代Xcode集成的是OCUnit，到了XCode5.x时代就升级为了XCTest,并且到了XCode7时代还有了进行UI测试的能力。除了官方自带的，还有一些比较出名的第三方的测试框架，如：GHUnit,KiWi，OCMock,Specta等,当然本文不讨论这些第三方框架。怎么知道我们的项目有没有加上单元测试，用Xcode打开你的项目，看文件导航栏有没有类似下图的两个文件夹（TestDemo是工程名）。
其实在我们新建工程的时候就可以为我们的工程选择是否带上单元测试，如下图：
如果你的项目没有上面说的两个文件，你可以通过新建一个Target的方式添加，如下图：
在test下选择你项目没有的便可：
在这2个文件夹目录下分别都有2个文件，一个.m文件和一个plist文件。并且.m文件有4个方法，如下图：
项目名+Test的.m文件里面默认有4个方法，这个文件里面主要做一些逻辑的测试。项目名+UITest的.m文件里默认有3个方法。这个文件里面主要做一些UI的测试。说了这么半天，该如何写单元测试呢？在讲解如何写测试方法前，先说说默认的方法是干什么的吧！
//TestDemoTest.m
- (void)setUp {
[super setUp];
//每个test方法执行前调用，在这个测试用例里进行一些通用的初始化工作
// Put setup code here. This method is called before the invocation of each test method in the class.
- (void)tearDown {
// Put teardown code here. This method is called after the invocation of each test method in the class.
[super tearDown];
//每个test方法执行后调用
- (void)testExample {
//测试方法样例
// This is an example of a functional test case.
// Use XCTAssert and related functions to verify your tests produce the correct results.
- (void)testPerformanceExample {
//这个方法主要是做性能测试的，所谓性能测试，主要就是评估一段代码的运行时间。该方法就是性能测试方法的样例。
// This is an example of a performance test case.
[self measureBlock:^{
// Put the code you want to measure the time of here.
测试用例方法非常简单，从testExample这个方法我们大概知道怎么写了吧！方法名只需要以test开头，是的，就是这么简单。现在我们模拟登录这个功能来写一个登录模块的测试用例吧，Demo代码在,在User这个模型类里面一个方法叫isChinese的，是用来判断字符串里面是否有中文的。
#import &Foundation/Foundation.h&
@interface User : NSObject
@property (nonatomic, copy) NSString *userN
@property (nonatomic, copy) NSString *passW
判断字符串中是否有中文
- (BOOL)isChinese:(NSString *)
现在我们通过Xcode的File-&New-&File-&Source选择Unit Test Case Class来新建一个UserTests,注意要继承XCTestCase类。
接下来我们为User类写一个测试isChinese方法的测试方法，叫做testIsChinese,测试用例具体如下：
UserTests.m
这样，你只要点击测试方法旁边的那个菱形的按钮就可以运行该测试方法啦！通过测试会变成绿色的对勾，失败会变成红色的叉叉。到这里测试用例你就会写了。也许你会在意那些断言，这样的断言有18个，如下：
XCTFail(format…)
//生成一个失败的测试；
XCTAssertNil(a1, format...)
//为空判断，a1为空时通过，反之不通过；
XCTAssertNotNil(a1, format…) //不为空判断，a1不为空时通过，反之不通过；
XCTAssert(expression, format...) //当expression求值为TRUE时通过；
XCTAssertTrue(expression, format...) //当expression求值为TRUE时通过；
XCTAssertFalse(expression, format...)
//当expression求值为False时通过；
XCTAssertEqualObjects(a1, a2, format...)
//判断相等，[a1 isEqual:a2]值为TRUE时通过，其中一个不为空时，不通过；
XCTAssertNotEqualObjects(a1, a2, format...)
//判断不等，[a1 isEqual:a2]值为False时通过；
XCTAssertEqual(a1, a2, format...)
//判断相等（当a1和a2是 C语言标量、结构体或联合体时使用,实际测试发现NSString也可以）；
XCTAssertNotEqual(a1, a2, format...)
//判断不等（当a1和a2是 C语言标量、结构体或联合体时使用）；
XCTAssertEqualWithAccuracy(a1, a2, accuracy, format...)
//判断相等，（double或float类型）提供一个误差范围，当在误差范围（+/-accuracy）以内相等时通过测试；
XCTAssertNotEqualWithAccuracy(a1, a2, accuracy, format...)
//判断不等，（double或float类型）提供一个误差范围，当在误差范围以内不等时通过测试；
XCTAssertThrows(expression, format...)
//异常测试，当expression发生异常时通过；反之不通过；
XCTAssertThrowsSpecific(expression, specificException, format...)
//异常测试，当expression发生specificException异常时通过；反之发生其他异常或不发生异常均不通过；
XCTAssertThrowsSpecificNamed(expression, specificException, exception_name, format...)
//异常测试，当expression发生具体异常、具体异常名称的异常时通过测试，反之不通过；
XCTAssertNoThrow(expression, format…)
//异常测试，当expression没有发生异常时通过测试；
XCTAssertNoThrowSpecific(expression, specificException, format...)
//异常测试，当expression没有发生具体异常、具体异常名称的异常时通过测试，反之不通过；
XCTAssertNoThrowSpecificNamed(expression, specificException, exception_name, format...)
//异常测试，当expression没有发生具体异常、具体异常名称的异常时通过测试，反之不通过
用代码写UI测试比较麻烦，但是苹果在Xcode中为我们提供了录制的功能。录制是怎么一回事呢？当你打开时这个功能时，测试代码会随着你在设备或模拟器上操作自动创建。这么一来就省事多了。现在，我们在TestDemoUITests.m文件中写一个方法testLogin作为测试登录流程操作的UI测试方法。然后把光标放在方法体内，然后点击红色的那个录制按钮，如下：
当你点击了录制后，程序就会自动启动，这时候你在程序的所有操作都会生成想用的代码在你所选择的方法体内。我录制了一个GIF，你可以看一下，非常的好用：
接下来我们看看里面的代码：
//XCUIApplication 这是应用的代理，他能够把你的应用启动起来，并且每次都在一个新进程中。
XCUIApplication *app = [[XCUIApplication alloc] init];
//XCUIElement 这是 UI 元素的代理。元素都有类型和唯一标识。可以结合使用来找到元素在哪里，如当前界面上的一个输入框
XCUIElement *usernameTextField = app.textFields[@"username:"];
[usernameTextField tap];
[usernameTextField typeText:@"xiaofei"];
XCUIElement *passwordTextField = app.textFields[@"password:"];
[passwordTextField tap];
[passwordTextField tap];
[passwordTextField typeText:@"12345"];
[[[[[[[app childrenMatchingType:XCUIElementTypeWindow] elementBoundByIndex:0] childrenMatchingType:XCUIElementTypeOther].element childrenMatchingType:XCUIElementTypeOther].element childrenMatchingType:XCUIElementTypeOther].element childrenMatchingType:XCUIElementTypeOther].element tap];
[app.buttons[@"login"] tap];
有了这些代码，我们就可以对它进行一些处理了，比如：
//XCUIApplication 这是应用的代理，他能够把你的应用启动起来，并且每次都在一个新进程中。
XCUIApplication *app = [[XCUIApplication alloc] init];
//XCUIElement 这是 UI 元素的代理。元素都有类型和唯一标识。可以结合使用来找到元素在哪里，如当前界面上的一个输入框
XCUIElement *usernameTextField = app.textFields[@"username:"];
[usernameTextField tap];
[usernameTextField typeText:@"xiaofei"];
XCUIElement *passwordTextField = app.textFields[@"password:"];
[passwordTextField tap];
[passwordTextField tap];
[passwordTextField typeText:@"12345"];
[[[[[[[app childrenMatchingType:XCUIElementTypeWindow] elementBoundByIndex:0] childrenMatchingType:XCUIElementTypeOther].element childrenMatchingType:XCUIElementTypeOther].element childrenMatchingType:XCUIElementTypeOther].element childrenMatchingType:XCUIElementTypeOther].element tap];
[app.buttons[@"login"] tap];
//登录成功后的控制器的title为loginSuccess，只需判断控制器的title时候一样便可判断登录是否成功
XCTAssertEqualObjects(app.navigationBars.element.identifier, @"loginSuccess");
如果你想一次跑完所有的测试方法，快捷键cmd+u即可。跑起来后的面板主要如下图所示：
这只是苹果官方集成在Xcode中的简单框架，优点就是简单，缺点也是简单。当然它的用法也绝非如此，有很多还待开发。苹果官方也有一个Demo，地址
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
打开微信“扫一扫”，打开网页后点击屏幕右上角分享按钮
被以下专题收入，发现更多相似内容：
分享 iOS 开发的知识，解决大家遇到的问题，讨论iOS开发的前沿，欢迎大家投稿~
? 26636人关注
学习从点滴开始 !
(PS: 拒绝部分投稿的文章仅仅是由于专题内已收录相关知识点的文章, 并非是投稿的文章技术含量不够好, 望谅解.)
? 5299人关注
心情不好的时候问自己 ：
我为何这么?
心情好的时候问自己 ： 为什么比我?的这么多
? 3676人关注
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
选择支付方式：对应用进行单元测试-手机软件-电脑编程网对应用进行单元测试作者：bstprogramer　和相关&&
在实际开发中，开发android软件的过程需要不断地进行测试。而使用Junit测试框架，侧是正规的Android开发的必用技术，在Junit中可以得到组件，可以模拟发送事件和检测程序处理的正确性。
第一步：首先在AndroidManifest.xml中加入下面红色代码:
&manifest xmlns:android=&/apk/res/android&
&&&&& package=&cn.itcast.action“ android:versionCode=&1“& android:versionName=&1.0&&
&&application android:icon=&@drawable/icon& android:label=&@string/app_name&&
&&&&&&& &uses-library android:name=&android.test.runner& /&
&&&&&&& ....
&&/application&
&&uses-sdk android:minSdkVersion=&6& /&
&&instrumentation android:name=&android.test.InstrumentationTestRunner&
& android:targetPackage=&cn.itcast.action& android:label=&Tests for My App& /&
&/manifest&
上面targetPackage指定的包要和应用的package相同。
第二步：编写单元测试代码（选择要测试的方法，右键点击“Run As”--“Android Junit Test” ）：
import android.test.AndroidTestC
import android.util.L
public class XMLTest extends AndroidTestCase {
&public void testSomething() throws Throwable {
Assert.assertTrue(1 + 1 == 3);
&}
}
l
相关资料：｜｜｜｜｜｜｜对应用进行单元测试来源网络，如有侵权请告知，即处理！编程Tags：　　　　　　　　　　　　　　　　&　　　　　　　　　　　　　　　　　　　　如何编写单元测试 - jack_Meng - 博客园
随笔 - 620, 文章 - 1, 评论 - 67, 引用 - 0
如何编写单元测试
一 单元测试简介
单元测试是代码正确性验证的最重要的工具，也是系统测试当中最重要的环节。也是唯一需要编写代码才能进行测试的一种测试方法。在标准的开发过程中，单元测试的代码与实际程序的代码具有同等的重要性。每一个单元测试，都是用来定向测试其所对应的一个单元的数据是否正确。
单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
单元测试还具有一下几个好处：
& 能够协助程序员尽快找到BUG的具体位置
& 能够让程序员对自己的程序更有自信
& 能够让程序员在提交项目之前就将代码变的更加健壮
& 能够协助程序员更好的进行开发
& 能够向其他程序员展现你的程序该如何调用
& 能够让项目主管更了解系统的当前状况
1.1&&& 能够协助程序员尽快找到BUG的具体位置
在没有单元测试的时代，我们大多数的错误都是通过操作页面的时候发现的。当我们发现一个错误的时候，会根据异常抛出的地点来确定是哪段代码出现了问题。但是大多数时候，我们不会所有方法中都使用Try块去处理异常（这一也是低效的）。因此一旦发现一个异常通常都是最顶层代码抛出的，但是错误往往又是在底层很深层次的某个对象中出现的。当我们找到了这个最初抛出异常的方法的时候，我们可能无法得知这段代码到底是哪里出了问题。只能逐行代码的去查找，一旦这个方法中使用的某个对象在外部有注册事件或者有其他的操作正在与当前方法同步进行，那么就更难发现错误真正的原因了。
有经验的程序员也会知道，大多数的时候，我们并不是真正的在编写新的代码，而是在修改旧的代码出现的错误。通常这个比例会大于2比8，这也是编写代码的时候的二八现象&&编写代码的时间是二，而为这段代码找错误、修改错误所花费的时间却是八。
在这种状态之下，我们在找错误的时候会直接编译整个程序，然后通过界面逐步的操作到错误的地方然后再去查找代码中是否有错误。这样的找错误的方法效率非常低。但是当我们拥有单元测试的时候，我们就不需要通过界面去一步一步的操作，而是直接运行这个方法的单元测试，将输入的条件模拟成出现错误的时候输入的信息和调用的方法的形式，这样就可能很快的还原出错误。这样解决起来速度就提高了很多，每次找到错误都去修改单元测试，那么下次就不会再出现相同的错误了。
如果通过模拟，单元测试也没有出现任何异常，这时也可以断定，并非该代码出现的错误，而是其他相关的代码出现的错误。我们只需再调试其他几个相关的代码的单元测试即可找到真正的错误。
1.2&&& 能够让程序员对自己的程序更有自信
很多时候，当主管问我们程序会不会再出问题的时候，我们会很难回答。因为我们没法估计到系统还可能出现什么问题。但是如果这时我们为所有代码都编写了单元测试，而且测试代码的编写是按照标准去写的，这些测试又都能够成功的通过测试。那么我们就完全有自信说出我们的把握有多大。因为在测试代码中，我们已经把所有可能的情况都预料到了，程序代码中也将这些可能预料到的问题都解决了。因此我们会对自己的程序变得越来越自信。
1.3&&& 能够让程序员在提交项目之前就将代买变得更加健壮
大多数程序员在编写代码的时候，都会先考虑最理想化情况下的程序该如何写，写完之后在理想状态下编译成功，然后输入理想的数据发现没有问题。他们就会自我安慰的说&完成了&。然后可能为了赶进度，就又开始作另外的程序了。时间久了这种理想化的程序就越来越多。一旦提交测试，就发现这里有错误那里有错误，然后程序员们再拿出时间来这里补个漏洞那里补个漏洞。而且在补漏洞的过程中，也可能继续沿用这种理想化的思路，就导致了补了这里又导致那里出问题的情况。
但是如果在初期，我们就为每段代码编写单元测试，而且根据一些既定的标准去写，那么单元测试就会提前告诉程序员哪些地方会出现错误。那么他们可能在编写过程中就提前处理了那些非理想状态下的问题。这样我们的代码就会健壮很多。
1.4&&& 能够协助程序员更好的进行开发
&码未动，测试现行。&这是极限编程中倡导的一种编程模式，为什么要这样呢？因为我们在编写单元测试的过程中，其实就是在设计我们的代码将要处理哪些问题。单元测试写的好，就代表你的代码写的好。而且你会根据单元测试的一些预先设想的情况去编写代码，就不会盲目的添加一个属性、添加一个方法了。
1.5&&& 能够向其他程序员展现你的程序该如何调用
通常情况下，单元测试代码中写的都是在各种情况下如何调用那段待测试的代码。因此这个单元测试同时也向其他人员展示了我们的代码该如何调用？在什么情况下会抛出什么异常？等等。这样一个单元测试就变成了一个代码性的帮助文档了。
1.6&&& 能够让项目主管更了解系统当前的状况
传统的管理中，项目的进度、代码的质量都只是通过口头的形式传递到主管那里的。因此有时候主管获得的反馈可能事实。但是如果通过一个完善的单元测试系统，那么主管就可以通过查看单元测试的运行结果和单元测试的代码覆盖率来确定开发人员的工作是否真正完成。
二 如何编写单元测试
Microsoft Visual Studio 2005中集成了一个专门用来进行测试的组件，该组件能够提供给我们单元测试、压力测试、代码覆盖率等等的测试相关的功能。我们无须借用第三方的测试工具来进行这些测试。
2.1& 创建单元测试
该工具可以对任何类、接口、结构等实体中的字段、属性、构造函数、方法等进行单元测试。创建单元测试大致可以分为两类：
& 整体测试，整体测试是在类名称上右击鼠标，在下拉菜单中点击创建单元测试选项。这样就可以为整个类创建单元测试了，这时他会为整个类可以被测试的内容全部添加测试方法。开发人员直接在这些自动生成的测试方法中添加单元测试代码就可以了。
& 单独测试，如果只想单独对某个方法、属性、字段进行测试，则可以将鼠标焦点放在这个待测试的项目名称之上，然后点击鼠标右键，在右键菜单中选择创建单元测试选项。这样就可以单独为某个方法创建单元测试了。
2.2& 编写单元测试代码
创建完单元测试之后，就可以为单元测试编写测试代码了。具体的测试代码的编写标准会在第三章中介绍。
2.3& 运行单元测试
单元测试代码编写完毕，就可以通过运行单元测试来进行测试了。需要运行单元测试的时候，需要打开测试管理器窗口。该窗口可以通过菜单中的&测试&－&窗口&&&&测试管理器&来打开。打开该窗口之后，就可以在该窗口中看到我们所建立的单元测试的列表。我们可以在列表中勾选某个单元测试前面的复选框。然后右击鼠标在右键菜单中点击&调试选中的测试&或者&运行选中的测试&。
调试选中的测试的时候，我们可以在测试代码中或者我们自己的代码中添加断点并逐步运行以看其状态。
运行选中的测试只会运行测试并不能够进行测试，这时代码的运行是模拟真实软件运行的时候的情况执行的。我们可以根据我们的实际情况来选中执行哪种测试。
2.4& 测试结果
运行了测试之后，我们需要查看这次测试的结果。我们可以通过点击菜单中的&测试&&&&窗口&&&&测试结果&来打开一个测试结果窗口。每次测试都会在测试结果中向我们显示一些记录。我们也可以通过双击这个测试结果，来查看详细的结果信息。
2.5& 代码覆盖率
单元测试写的是否合理或者是否达到了要求的一个唯一的标准就是整个测试的代码覆盖率。代码覆盖率其实就是测试代码所运行到的实际程序路径的覆盖率。在实际程序中可能会有很多的循环、判断等分支路径。一个好的单元测试应该能够将所有可能的路径都将走到，这样就可以保证大多数情况都测试过了。
VS2005中也提供了查看代码覆盖率的工具。我们可以通过点击菜单中的&测试&&&&窗口&&&&代码覆盖率结果&来打开代码覆盖率查看的窗口。
若要进行代码覆盖率的检查，我们必须进行设置，因为系统默认情况下是不进行代码覆盖率检测的。若要打开某个测试的代码覆盖率测试，我们必须点击菜单中的&测试&&&&编辑测试运行配置&&&&本地测试运行。。。。。。&来打开一个测试配置窗口。在该窗口左侧的列表中选中&代码覆盖率&就会显示代码覆盖率的设置。在这个配置中会显示当前解决方案中可以用来检测代码覆盖率的程序集，我们将需要进行覆盖率检测的程序集选中然后点击&应用&按钮就可以了。
设置完毕之后，我们就可以直接运行单元测试，测试通过后。我们就可以打开代码覆盖率结果窗口，在这里我们就能够看到这些测试覆盖了多少代码。当我们在这里双击某个类的时候，就可以看到VS已经将代码背景改变了颜色。显示为深棕色的代码就是没有覆盖到的代码，我们可以通过在单元测试代码中添加代码来想办法覆盖这些代码。这样一个单元测试的全过程就完成了。
三& 单元测试的标准
虽然要进行单元测试的代码会是各种各样的，但是编写单元测试代码还是有规律可循的。测试的对象一般情况下分为方法（包含构造函数）、属性，因此我们按照这两个方向来确定单元测试的标准。
由于现在大多数开发人员还没有真正使用过.NET的单元测试工具，对于单元测试的了解程度也不高。因此我们这里也不便于制定非常多的标准。我们当前主要针对两大方面进行规范：
l& 哪些代码需要添加单元测试？
l& 单元测试代码的写法？
3.1& 哪些代码需要添加单元测试
当前项目正处在一个最后冲刺阶段，主要的大部分编码工作已经基本完成。因此要全面的添加单元测试，其实是比较大的投入。所以单元测试不能一次性的全部加上，我们只能通过一步一步的来进行测试。
第一步，应该对所有程序集中的公开类以及公开类里面的公开方法添加单元测试。
第二步，对于构造函数和公共属性进行单元测试。
第三步，添加全面单元测试。
在产品全面提交之前可以先完成第一步的工作，二三步可以待其他所有功能完成之后再进行添加。由于第二三步的添加工作其实于第一步类似，只是在量上的累加，因此我们先着重讨论第一步的情况。
在作第一步单元测试添加的时候，也需要有选择性的进行，我们要抓住重点进行测试。首先应该针对属于框架技术中的代码添加单元测试。这里就包含操作数据库的组件、操作外部WebService的组件、邮件接收发送组件、后台服务与前提程序之间的消息传递的组件等等。通过为这些主要的可复用代码进行测试，可以大大加强底层操作的正确性和健壮性。
其次为业务逻辑层对界面公开的方法添加单元测试。这样可以让业务逻辑保持正确，并且能够将大部分的业务操作都归纳到单元测试中，保证以后产品发布之后，一旦出现问题可以直接通过业务逻辑的单元测试来找到BUG。
剩下的代码大部分属于代码生成器生成的，而且大多数的操作都是类似的，因此我们可以先针对某一个业务逻辑对象做详细的单元测试。通过这样的规定，单元测试添加的范围就减少了很多。
3.2& 单元测试代码的写法
在编写单元测试代码的时候需要认真的考虑以下几个方面：
l& 所测试的方法的代码覆盖率必须达到100％。
l& 所测试的代码内部的状态，例如执行了某个方法之后，该方法所在的类中某个属性或者返回值是否与预期相同。
l& 被测试代码所使用的外部设备的状态，如数据库是否可读、网络是否可用、打印机是否可用、WebService是否可用等等。
每一段单元测试代码，必须考虑到以上的三个问题，并且对于这些问题都要有相应的测试。
3.2.1& 代码覆盖率要求
在2.5小节中已经讲了什么是代码覆盖率和代码覆盖率查看的方法。在这里我们着重来讲怎样将代码覆盖率提升到100％。
一般情况下，代码覆盖率低，说明测试代码中没有过多的考虑某些特殊情况。特殊情况包括：
l& 边界条件数据，比如值类型数据的最大值、最小值、DBNull，或者是方法中所使用的条件边界，例如a&100那么100就变成了这个数据的边界。而且在测试的时候还必须把超出边界的数据作为测试条件进行测试。
l& 空数据，一般空数据对应于引用类型的数据，也就是Null值。
l& 格式不正确数据，对于引用类型的数据或者结构对象，类型虽然正确但是其内部的数据结构不正确的数据。例如一个数据库实体对象，数据库中要求其某个属性必须为非空，但是这时我们可以属于一个空。这样这个对象就属于一个不正确数据库。
这三种数据都是针对被测试方法中所使用的外部数据来说的。方法中使用的外部数据无非就是方法参数传入的数据和方法所在的对象的属性或者字段的数据。因此在编写测试代码的时候就必须将这些使用到的数据设置为上面这几种情况的数据来检测方法执行的情况。这才能保证方法编写是正确的。
在编写单元测试代码的时候先了解到被测试方法可能会使用的外部数据，然后将这些外部数据一次设置为上面规定的这几种情况，然后再执行方法。这样就基本可以达到外部数据所有情况都能够正确测试到了。
通过这种方法编写的单元测试代码覆盖率一般可以超过80％。
3.2.2& 预期值是否达到
在编写单元测试的时候，不能单纯的追求代码覆盖率。有时候代码覆盖率已经达到了100％，程序也能正常运行，但是可能会出现方法执行完毕之后某些数据并非预期的数值。这时就必须对执行的结果进行断言。在.NET提供的单元测试模块中，可以在单元测试中直接使用一个类的一些静态方法来判断某个值是否达到了预期的情况。这个类是Assert。在这个类中公开了很多判断等效性、判断开关性、判断非空性等一系列方法。这些方法可以让你提前做出预测，一旦程序执行之后，如果这些断言不能通过，就代表代码有错误。
在使用断言的时候，我们要求要达到平均5行测试代码就要有一个断言。
通过添加断言，我们就可以对程序执行过程中数据的正确性做一个检测，保证我们的程序不出现写错数据的情况或者出现错误状态的情况。
3.2.3& 外部设备状态更改时测试是否正常通过
当代码覆盖率和预期值都达到了我们的要求之后，整个程序其实就基本达到了质量标准。但是这样还不全面，因为很多程序都要使用到外部的设备或者程序，例如数据库、打印机、网络、串行口、并行口等等。当这些设备发生改变或者不可用的时候，程序就可能出现一些不可预知的错误。因此一个健壮的程序也必须考虑到这些情况，这时通常都是通过将这些设备确定的设置为这些不正常状态来检测程序可能会出现的问题。然后再在测试程序中将这些条件加上。
中科永联高级技术培训中心（）关于单元测试的一些解释
单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把一个很大的值放入一个有序list 中去，然后确认该值出现在list 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。
& && &单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
& && &工厂在组装一台电视机之前，会对每个元件都进行测试，这，就是单元测试。
　　其实我们每天都在做单元测试。你写了一个函数，除了极简单的外，总是要执行一下，看看功能是否正常，有时还要想办法输出些数据，如弹出信息窗口什么的，这，也是单元测试，老纳把这种单元测试称为临时单元测试。只进行了临时单元测试的软件，针对代码的测试很不完整，代码覆盖率要超过70%都很困难，未覆盖的代码可能遗留大量的细小的错误，这些错误还会互相影响，当BUG暴露出来的时候难于调试，大幅度提高后期测试和维护成本，也降低了开发商的竞争力。可以说，进行充分的单元测试，是提高软件质量，降低开发成本的必由之路。
　　对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。
　　要进行充分的单元测试，应专门编写测试代码，并与产品代码隔离。老纳认为，比较简单的办法是为产品工程建立对应的测试工程，为每个类建立对应的测试类，为每个函数（很简单的除外）建立测试函数。首先就几个概念谈谈老纳的看法。
　　一般认为，在结构化程序时代，单元测试所说的单元是指函数，在当今的面向对象时代，单元测试所说的单元是指类。以老纳的实践来看，以类作为测试单位，复杂度高，可操作性较差，因此仍然主张以函数作为单元测试的测试单位，但可以用一个测试类来组织某个类的所有测试函数。单元测试不应过分强调面向对象，因为局部代码依然是结构化的。单元测试的工作量较大，简单实用高效才是硬道理。
　　有一种看法是，只测试类的接口(公有函数)，不测试其他函数，从面向对象角度来看，确实有其道理，但是，测试的目的是找错并最终排错，因此，只要是包含错误的可能性较大的函数都要测试，跟函数是否私有没有关系。对于C++来说，可以用一种简单的方法区隔需测试的函数：简单的函数如数据读写函数的实现在头文件中编写(inline函数)，所有在源文件编写实现的函数都要进行测试(构造函数和析构函数除外)。
为什么要使用单元测试
& & 我们编写代码时，一定会反复调试保证它能够编译通过。如果是编译没有通过的代码，没有任何人会愿意交付给自己的老板。但代码通过编译，只是说明了它的语法正确；我们却无法保证它的语义也一定正确，没有任何人可以轻易承诺这段代码的行为一定是正确的。
& & 幸运，单元测试会为我们的承诺做保证。编写单元测试就是用来验证这段代码的行为是否与我们期望的一致。有了单元测试，我们可以自信的交付自己的代码，而没有任何的后顾之忧。
　　什么时候测试？单元测试越早越好，早到什么程度？XP开发理论讲究TDD，即测试驱动开发，先编写测试代码，再进行开发。在实际的工作中，可以不必过分强调先什么后什么，重要的是高效和感觉舒适。从老纳的经验来看，先编写产品函数的框架，然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产品函数的代码，每写一个功能点都运行测试，随时补充测试用例。所谓先编写产品函数的框架，是指先编写函数空的实现，有返回值的随便返回一个值，编译通过后再编写测试代码，这时，函数名、参数表、返回类型都应该确定下来了，所编写的测试代码以后需修改的可能性比较小。
　　由谁测试？单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。测试部门可以作一定程度的审核。
　　关于桩代码，老纳认为，单元测试应避免编写桩代码。桩代码就是用来代替某些代码的代码，例如，产品函数或测试函数调用了一个未编写的函数，可以编写桩函数来代替该被调用的函数，桩代码也用于实现测试隔离。采用由底向上的方式进行开发，底层的代码先开发并先测试，可以避免编写桩代码，这样做的好处有：减少了工作量；测试上层函数时，也是对下层函数的间接测试；当下层函数修改时，通过回归测试可以确认修改是否导致上层函数产生错误。
& & 在一种传统的结构化编程语言中，比如C，要进行测试的单元一般是函数或子过程。在象C++这样的面向对象的语言中， 要进行测试的基本单元是类。对Ada语言来说，开发人员可以选择是在独立的过程和函数，还是在Ada包的级别上进行单元测试。单元测试的原则同样被扩展到第四代语言(4GL)的开发中，在这里基本单元被典型地划分为一个菜单或显示界面。
　　单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行维护。
　　经常与单元测试联系起来的另外一些开发活动包括代码走读(Code
review)，静态分析(Static
analysis)和动态分析(Dynamic
analysis)。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。
一些流行的误解
　　在明确了什么是单元测试以后，我们可以进行"反调论证"了。在下面的章节里，我们列出了一些反对单元测试的普遍的论点。然后用充分的理由来证明这些论点是不足取的。
& && &它浪费了太多的时间
　　一旦编码完成，开发人员总是会迫切希望进行软件的集成工作，这样他们就能够看到实际的系统开始启动工作了。 这在外表上看来是一项明显的进步，而象单元测试这样的活动也许会被看作是通往这个阶段点的道路上的障碍， 推迟了对整个系统进行联调这种真正有意思的工作启动的时间。
　　在这种开发步骤中，真实意义上的进步被外表上的进步取代了。系统能够正常工作的可能性是很小的，更多的情况是充满了各式各样的Bug。在实践中，这样一种开发步骤常常会导致这样的结果：软件甚至无法运行。更进一步的结果是大量的时间将被花费在跟踪那些包含在独立单元里的简单的Bug上面，在个别情况下，这些Bug也许是琐碎和微不足道的，但是总的来说，他们会导致在软件集成为一个系统时增加额外的工期， 而且当这个系统投入使用时也无法确保它能够可靠运行。
　　在实践工作中，进行了完整计划的单元测试和编写实际的代码所花费的精力大致上是相同的。一旦完成了这些单元测试工作，很多Bug将被纠正，在确信他们手头拥有稳定可靠的部件的情况下，开发人员能够进行更高效的系统集成工作。这才是真实意义上的进步，所以说完整计划下的单元测试是对时间的更高效的利用。而调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。
　　使用AdaTEST和Cantata这样的支持工具可以使单元测试更加简单和有效。但这不是必须的，单元测试即使是在没有工具支持的情况下也是一项非常有意义的活动。
& && &它仅仅是证明这些代码做了什么
　　这是那些没有首先为每个单元编写一个详细的规格说明而直接跳到编码阶段的开发人员提出的一条普遍的抱怨， 当编码完成以后并且面临代码测试任务的时候，他们就阅读这些代码并找出它实际上做了什么，把他们的测试工作基于已经写好的代码的基础上。当然，他们无法证明任何事情。所有的这些测试工作能够表明的事情就是编译器工作正常。是的，他们也许能够抓住(希望能够)罕见的编译器Bug，但是他们能够做的仅仅是这些。
　　如果他们首先写好一个详细的规格说明，测试能够以规格说明为基础。代码就能够针对它的规格说明，而不是针对自身进行测试。这样的测试仍然能够抓住编译器的Bug，同时也能找到更多的编码错误，甚至是一些规格说明中的错误。好的规格说明可以使测试的质量更高，所以最后的结论是高质量的测试需要高质量的规格说明。
　　在实践中会出现这样的情况： 一个开发人员要面对测试一个单元时只给出单元的代码而没有规格说明这样吃力不讨好的任务。你怎样做才会有更多的收获，而不仅仅是发现编译器的Bug？第一步是理解这个单元原本要做什么， --- 不是它实际上做了什么。 比较有效的方法是倒推出一个概要的规格说明。这个过程的主要输入条件是要阅读那些程序代码和注释， 主要针对这个单元， 及调用它和被它调用的相关代码。画出流程图是非常有帮助的，你可以用手工或使用某种工具。 可以组织对这个概要规格说明的走读(Review)，以确保对这个单元的说明没有基本的错误， 有了这种最小程度的代码深层说明，就可以用它来设计单元测试了。
& && &我是个很棒的程序员，
我是不是可以不进行单元测试？
　　在每个开发组织中都至少有一个这样的开发人员，他非常擅长于编程，他们开发的软件总是在第一时间就可以正常运行，因此不需要进行测试。你是否经常听到这样的借口？
　　在真实世界里，每个人都会犯错误。即使某个开发人员可以抱着这种态度在很少的一些简单的程序中应付过去。 但真正的软件系统是非常复杂的。真正的软件系统不可以寄希望于没有进行广泛的测试和Bug修改过程就可以正常工作。
　　编码不是一个可以一次性通过的过程。在真实世界中，软件产品必须进行维护以对操作需求的改变作出反应， 并且要对最初的开发工作遗留下来的Bug进行修改。你希望依靠那些原始作者进行修改吗？ 这些制造出这些未经测试的原始代码的资深专家们还会继续在其他地方制造这样的代码。在开发人员做出修改后进行可重复的单元测试可以避免产生那些令人不快的负作用。
& && &不管怎样，
集成测试将会抓住所有的Bug
　　我们已经在前面的讨论中从一个侧面对这个问题进行了部分的阐述。这个论点不成立的原因在于规模越大的代码集成意味着复杂性就越高。如果软件的单元没有事先进行测试，开发人员很可能会花费大量的时间仅仅是为了使软件能够运行，而任何实际的测试方案都无法执行。
　　一旦软件可以运行了，开发人员又要面对这样的问题： 在考虑软件全局复杂性的前提下对每个单元进行全面的测试。 这是一件非常困难的事情，甚至在创造一种单元调用的测试条件的时候，要全面的考虑单元的被调用时的各种入口参数。在软件集成阶段，对单元功能全面测试的复杂程度远远的超过独立进行的单元测试过程。
　　最后的结果是测试将无法达到它所应该有的全面性。一些缺陷将被遗漏，并且很多Bug将被忽略过去。
　　让我们类比一下，假设我们要清洗一台已经完全装配好的食物加工机器!无论你喷了多少水和清洁剂，一些食物的小碎片还是会粘在机器的死角位置，只有任其腐烂并等待以后再想办法。但我们换个角度想想，如果这台机器是拆开的， 这些死角也许就不存在或者更容易接触到了，并且每一部分都可以毫不费力的进行清洗。
& && &它的成本效率不高
　　一个特定的开发组织或软件应用系统的测试水平取决于对那些未发现的Bug的潜在后果的重视程度。这种后果的严重程度可以从一个Bug引起的小小的不便到发生多次的死机的情况。这种后果可能常常会被软件的开发人员所忽视(但是用户可不会这样)，这种情况会长期的损害这些向用户提交带有Bug的软件的开发组织的信誉，并且会导致对未来的市场产生负面的影响。相反地，一个可靠的软件系统的良好的声誉将有助于一个开发组织获取未来的市场。
　　很多研究成果表明，无论什么时候作出修改都要进行完整的回归测试，在生命周期中尽早地对软件产品进行测试将使效率和质量得到最好的保证。Bug发现的越晚，修改它所需的费用就越高，因此从经济角度来看， 应该尽可能早的查找和修改Bug。在修改费用变的过高之前，单元测试是一个在早期抓住Bug的机会。
　　相比后阶段的测试，单元测试的创建更简单，维护更容易，并且可以更方便的进行重复。从全程的费用来考虑， 相比起那些复杂且旷日持久的集成测试，或是不稳定的软件系统来说，单元测试所需的费用是很低的。
　　经验表明一个尽责的单元测试方法将会在软件开发的某个阶段发现很多的Bug，并且修改它们的成本也很低。在软件开发的后期阶段，Bug的发现并修改将会变得更加困难，并要消耗大量的时间和开发费用。无论什么时候作出修改都要进行完整的回归测试，在生命周期中尽早地对软件产品进行测试将使效率和质量得到最好的保证。 在提供了经过测试的单元的情况下，系统集成过程将会大大地简化。开发人员可以将精力集中在单元之间的交互作用和全局的功能实现上，而不是陷入充满很多Bug的单元之中不能自拔。
　　使测试工作的效力发挥到最大化的关键在于选择正确的测试策略，这其中包含了完全的单元测试的概念，以及对测试过程的良好的管理，还有适当地使用象AdaTEST和Cantata这样的工具来支持测试过程。这些活动可以产生这样的结果：在花费更低的开发费用的情况下得到更稳定的软件。更进一步的好处是简化了维护过程并降低了生命周期的费用。有效的单元测试是推行全局质量文化的一部分，而这种质量文化将会为软件开发者带来无限的商机。
参考出处：