读书笔记-实用单元测试(英文版) Pragmatic Unit Testing in C# with NUnit

读书笔记-实用单元测试(英文版)

Pragmatic Unit Testing in C# with NUnit

Author: Andrew Hunt ,David Thomas with Matt Hargett

Chapter1: 介绍.

1. 单元测试不是用户和管理人员使用的工具.而是程序员自己为自己写的,用于验证代码的工具.
2. 单元测试提高了我们对自己输写的程序的信心.
3. 单元测试可以证明程序是按照程序的意愿进行工作的.
4. 单元测试可以让我们把更多的时间放在coding上,而不是debugging上.
5. 新加入的测试与存在的测试一起运行,避免因需求变更对旧系统引入Bug.
6. 单元测试可以先于产品代码,也可后于,推荐先于,这样可以避免过度设计和太多的重构.
7. 因修改而引入bug,大多数情况下根本原因是不适当的耦合.
8. 不写单元测试的理由都是站不住脚的.
9. 遗留代码可以通过重构,一点一点到加入单元测试.
10. 在你的项目中看到下面的情况,就是重新评估一下你的单元测试做的是否到位:

　　　　1)单元测试实际上成了集成测试,需要大量的setup和测试代码,需要很长时间来运行,引入的数据库,网络等资源.

　　　　2) 单元测试只测试了一种情况,缺少异常情况的测试,没有通过测试表达出代码的实际用途.

　　　　3) 单元测试是不可维护的,当单元测试失败时忽略或删除它,当Bug出现时,没有新的单元测试加入.

 

Chapter2: 第一次单元测试

1. 在visual studio中”引用”的shortkey是ctrl+shift+B.
2. 在测试代码中有特定的attribute修改测试类和测试方式,如[TextFixture],[Text]
3. 异常情况的测试使用[ExpectedException]attribute.

 

Chapter3: 用NUnit写单元测试. (由于我不常用NUnit,这里就说的不多)

1. 测试代码遵循如下过程:

1)      根据测试对象,设置需要的条件和资源等等,如set up

2)      调用被测试的方法.

3)      验证结果 eg:assert

4)      打扫战场:tear down.

1. 一些常用的Assert用法.
2. Assert新引入的新特性.
3. 通过使用Category,组织测试策略,如[Category(“short”)], [Category(“long”)], [Category(“Fred”)].

 

Chapter4: 测试什么:RIGHT-BICEP

1. 测试什么:

1)      Right:所有测试结果都正确性吗?

2)      Boundry:边界测试都正确吗?

3)      Inverse: 是检查了相反关系.

4)      Cross-check:是否使用其它方式测试结果.

5)      Error:是否引入错误条件测试.

6)       Performance:性能测试是否在意料之中.

1. 可以在测试代码中引入其它的类或方法,以使用于重用.
2. 对于运行时间稍长的单元测试,不必每次都执行.保证自动构建时运行即可(每天一次即可).

 

Chapter5:边界条件测试:CORRECT

1. Conformance:一致性:与预期格式是否一致.
2. Ordering:顺序性,
3. Range:取值范围.
4. Reference:引用,是否引用外部环境.
5. Existence:对于参数来说,考虑参数传入为空时,函数是如何处理.
6. Time:考虑时间上函数的执行顺利,并发性(多线程条件下).还有不同国家地区的时差.

 

 

Chapter6:使用MOCK

1. MOCK对象其实就是真实对象在测试期间的代替对象.
2. 使用MOCK的场景:

1)      真实对象有着不确定的行为.(有着不可预测的结果).

2)      真实对象很难创建,像需要文件系统,数据库或网络.

3)      真实对象有着很难触发的行为,如网络错误.

4)      真实对象响应很慢.

5)      真实对象有或是一个用户界面.

6)      测试需要了解真实对象是如何使用的,如测试需要确认调用了一个回调函数.

7)      真实对象还不存在.

1. 使用MOCK对象,有三个关键的步骤:

1)      使用接口来描述对象的相关方法.

2)      用产品代码实现这个接口.

3)      在测试中使用MOCK实现这个接口.

1. 多数情况下可以不用使用singleton.
2. 有时通过简单的重构,我们可以不使用MOCK, 这样更加简单,高效.

 

 

Chapter7:一个好的测试的特点

1. 一个好的测试,要满足以下特点(A-TRIP)

1)      Automatic:自动化,测试可以自动执行,包括两方面: 执行测试和检查结果.

2)      Thorough:彻底的,主要是代码的测试覆盖率.

3)      Repeatable:可重复性.每一个测试都可重复执行.且产生同样的结果.

4)      Independent:每一个测试都是独立的,不与其他测试耦合.与测试顺序无关.

5)      Professional:职业的.测试代码与产品代码一样,需要保质保量.

1. 可以借助如:Cruise Control或其他的持续构建和测试的工具完成测试自动化.
2. 测试每一个测试都是有关注的,意思就是说,如果测试失败,则很容易定位错误发生的原因.
3. 如果有失败的测试,那么需要考虑:同样的情况在其他地方一样会发生吗?

 

 

Chapter8:在项目中的测试.

1. 推荐把测试代码与产品代码放在不同的程序集中.
2. 存在以下代码的情况下,不要把代码check in:

1)      代码还没有完成

2)      代码没有编译

3)      代码已经编译了,代码对已存在的代码的编译,造成影响.

4)      代码没有相应的单元测试.

5)      代码有失败单元测试.

6)      代码通过了自己的测试,但是影响了其他模块的测试结果.

1. 多少执行一次我们的单元测试呢,以下提供了一些意见:

1)      写了一个新的方法

2)      修正了一个bug

3)      每一次成功的编译

4)      每一次的成功check in

5)      持续集成时.

1. 遗留代码的测试:

1)      在遗留代码中进行开发,新写的代码一定要写单元测试.

2)      对遗留代码,我们根据情况选择那个可测的代码进行单元测试.

3)      对于那些不容易测试的代码,我们要进行重构,我们要选取最容易出错的代码,最常使用的代码进行单元测试.

5, 测试代码也应该是代码评审的一部分.

 

Chapter9:设计问题

1. 单元测试还可以帮助我们改进代码的架构设计:主要体现在以下方面

1)      更好的分离关注点:一个方法只做一个件事,更容易测试.

2)      定义类常量改进设计:尽量不要使用字符串进行判断.

3)      用测试驱动设计提高接口设计

4)      建立与本地化验证职责.

 

 

Chapter10:GUI测试

       ………………………………………….