单元测试检查清单:让你的测试保持有效,避免大的错误 【已翻译100%】

单元测试是测试你代码的一些常用方法集. 一般的操作步骤如下:

1.先写北侧类的API

2.测试对应API的方法名

3.实现对应测试API的方法体

4.运行单元测试

为什么需要单元测试? 它可以测试现有的以及未来的功能模块. 保证代码质量. 它规范你书写具有可测性,低耦合的代码.这比手工回归测试廉价的多. 它将提高代码可行度.协助团队工作.

为啥需要个检查列表? 单元测试在实际操作时可能要复杂一点. 它需要你考虑清楚整个待测对象的框架. 但测试本身应该简单,直接,易用和易维护. 对于测试的开始点和结束点也要十分清楚.

使用这个检查列表能帮助你确保测试范围的有效性. 切记: 该列表能帮助你绕开那些明显的错误,但有前提:

□ 一个测试类对应一个被测类.

  • o 你要测试的是一个已声明的类的正确性.

□ 一次只测试一个方法体.

  • o 私有方法不需要测试! 它们是被封装起来的.

□ 测试的方法名和变量都是显示定义的.

  • o 比如,将预期结果保存到 expectedFoo 变量就比 foo好得多. 如果要测试很多复合结果,可以使用组合的名称inputValue_NotNull, inputValue_ZeroData, inputValue_PastDate, etc. (取决于你的代码规范).

□ 测试用例易于理解.

  • o 后来的使用者将会很容易理解测试代码的大意而无需关注太多的具体实现. 这能帮助他们在调试之前知道工作的大概内容.

□ 测试用例符合代码整洁规范.

  • o 测试用例中不要包含流程控制语句 (switch, if, 等.). 好的用例就是很直接的数据准备,结果验证过程.如果场景需要,可以配上测试桩来优化代码结构. 对于多场景测试,书写多个对应的测试用例 (一一对应).
  • o 比如,一个测试用例代码长度最好在 – 1 到20行左右.如果测试代码太长,考虑拆开成独立的小测试集,以避免搅在一起.

□ 测试用例最好验证预期的异常.

  • o Java里用 @Test(expected=MyException.class).

□ 测试用例最好不要连接到数据库.

  • o或者说,如果测试中需要连接数据库操作,就使用mock “在每次新的测试开始注意测试时的数据库连接状态”连接,断开 (使用 Setup/Teardown).

□ 测试用例最好不要连接网络资源.

  • o 测试某个方法时没办法确保第三方的网络设备的有效性 (使用mocks).

□ 测试用例需要注意边际效应,极限值 (max, min) 和null的处理(就算是在异常中抛出的也要注意).

  • o就算在测试里这些内容不需要被维护,我们也要确保这些问题不会出现.

□ 测试用例不论在任何时候任何地方都无需人工干预来执行.

□ 测试用例测试了当前的代码但也能很容易的测试将来实现的代码.

  • o 测试就是为了确保代码的正确演变.如果没法易于扩展,那它就成了负担. (很多人不写单元测试用例就是这个原因.)

□ 测试用例具有一致性.

  • o 在Java: 别使用 Date()作为被测方法的输入数据,最好使用Calendar (别忘了时区配置). 再比如: 用name = “Smith”; 不要用 name = “name”; 或是name = “test”;

□ 测试用例使用mock来模拟复杂的代码结构或方法体.

  • o 记住一次只测试一个类.
  • o 不要在自己的类中测试第三方的类库. 类库的测试交给它们自己的测试 (这也是鉴别类库优劣的一条准则).

□ 不要注释掉测试用例 @ignored . 切记. 切记.

□ 测试帮助我确保了整体的架构设计.

  • o 如果有那个方法没办法被测试,说明设计的有问题.

□ 我的测试可以运行在任何平台,而非指定目标平台

  • 别指望一个特定的设备或硬件配置。否则你的测试会使迁移更困难,这里鼓励禁用它们。

□ 我的测试像闪电一般快!

  • 慢的测试不应该把你拖垮。速度鼓励你经常启动您的测试。它还有助于减少持续集成系统上的构建时间。
  • 使用测试运行程序,允许您在写测试时一次启动一个测试。要小心使用“delay”和“sleep”,比如只有在一些边缘情况下,像等待通知或基于时钟的方法。
时间: 2024-11-06 07:19:45

单元测试检查清单:让你的测试保持有效,避免大的错误 【已翻译100%】的相关文章

现代数据中心服务器维护检查清单

企业数据中心定期计划性的进行服务器维护可以防止发生大的问题,并保持一切正常运行.因此,数据中心管理人员们务必要为服务器的硬件和软件执行简单的检查腾出时间. 数据中心的服务器只是复杂一些的机器.与任何其他机器一样,这些服务区也同样需要定期性的维护,以便达到最佳性能.而通过简单的维护程序则可减少发生严重故障的可能性,进而延长服务器的使用寿命. 即使具备现代服务器的性能和冗余功能特征,增加的工作负载整合和可靠性预期也可能对您的企业的业务造成损失.故而您数据中心的服务器维护清单应涵盖相关的物理元素以及系

10条检查清单 为新站上线保驾护航

新站上线之前,开发者脑中往往有很多事情要考虑,但你可能没有检查清单.本文就为你整理了这些资料,它可能不是很权威,但是会帮你的网站打下一个好的基础,有一个好的开端. 1.有意义并且符合逻辑的结构 保持页面标题和内容的相关性是非常重要的.要谨记搜索引擎喜欢连字符而不是下划线.为了使内容页面到主页的点击距离尽可能少,应当采用少用目录的扁平的网站结构. 2.每一个页面都有相关且独特的标题 这是很容易忽视的一点,这不会削弱你站点的竞争力.一个没有标题的页面看起来不专业而丧失机会.火狐浏览器会简单的展示你的

Visual Studio 2008单元测试_数据“.NET研究”库测试

我们开发一个系统必须与数据库打交道,需要写N个SQL.存储过程.自定义函数.视图等,那么能否使用Visual Studio 2008进行数据库测试吗?当然是可以的,下面我就以一个简单的为例子,介绍如何利用Visual Studio 2008进行数据库单元测试. 第一步,在Visual 2008里面增加数据库测试,如下图所示: >这样我们就添加好一个数据库单元测试,下面就是如何设置此单元测试是针对哪个数据库的. 第二步:指定当前测试项目的数据库配置 当我们新增加一个数据库单元测试,Visual 2

《有效的单元测试》一3.2 测试替身的类型

3.2 测试替身的类型 你见过了使用测试替身的各种原因,我们也暗示了有多种测试替身可供选择.我们来仔细看看那些类型吧.图3.3展示了这把大伞下的四种对象. 既然我们已经制定了测试替身的分类,现在就来认识一下它们,并了解相互的区别,以及运用它们的典型目的.我们先从最简单的开始. 3.2.1 测试桩通常是短小的 我这样来定义它:桩(名词),截断的或非常短的物体.这衍生出测试桩的精确定义.测试桩(简称桩或Stub)的目的是用最简单的可能实现来代替真实实现.最基本的实现例子就是一个对象的所有方法都只有一

《有效的单元测试》一1.3 测试作为设计工具

1.3 测试作为设计工具 传统上,程序员编写的自动化测试被看做是质量保证工作,用于在编写的时候验证实现的正确性,以及将来代码进化的时候验证正确性.这就是将测试作为验证工具--你设想一份设计,编写代码实现,编写测试验证实现是否正确. 使用自动化测试作为设计工具将世界颠倒过来了.当你用测试设计代码时,你将典型的"设计,编码,测试"序列变换为"测试,编码,设计".是的,就是那样.测试先于编码,并以追溯性的设计活动来得出结论.那结论性的设计活动称为重构,序列变为"

阐述Checklist(检查清单)在Web软件产品测试中的应用

Checklist 汇集了有经验的http://www.aliyun.com/zixun/aggregation/9621.html">测试人员总结出来的最有效的测试想法,可以直接有效的指导测试工作,开阔测试人员的思路,能够快速的发现产品的缺陷并实现较好的测试覆盖,更重要的是该 Checklist 在不同的项目中具有很强的通用性.该系列文章中,将在每个部分给出具体的有效的 Checklist 并提供相关应用实例,以便于您的理解和应用. 在 Web 开发测试中,导航和链接为用户提供了丰富的操

《有效的单元测试》一3.1 测试替身的威力

3.1 测试替身的威力 甘地(Mahatma Gandhi)说过:"改变世界从自身做起".(Be the change you want to see in the world.)测试替身响应了甘地的召唤,成为你在代码中希望见到的变化.牵强附会?容我慢慢道来.代码是一个大集合.它是指代其他代码的代码网络.每一块都有预定义的行为--作为程序员的你定义了那些行为.某些行为是原子的,包含在单个类或方法中.某些行为意味着不同代码块之间的交互.为了时不时地验证一段代码的行为符合你的期望,最好的选

单元测试—使用模拟对象做交互测试

最近在看.net单元测试艺术,我也喜欢单元测试,这里写一下如何在测试中使用模拟对象. 开发的过程中,我们都会遇到对象间的依赖,比如依赖数据库或文件,这时,我们需要使用模拟对象,来进行测试,我们可以手写模拟对象,当然也可以使用模拟框架. 假如有这样的一个需求,当用户登陆时,我需要对用户名和密码进行验证,然后再将用户名写入日志中. public class MyLogin { public ILog Log { get; set; } public bool Valid(string userNam

测试-hibernate 求各位大神 帮忙看一下

问题描述 hibernate 求各位大神 帮忙看一下 我做的一个Hibernate 一对多 多对一的 保存和读取操作 保存 没问题 但是 读取那老是提示 内存溢出 下面是 实体类 Department 类 有setter 和getter 方法 private Integer id; private String name; private Set employees=new HashSet(); public Integer getId() { return id; } public void