BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

更好的单元测试准则

| 作者 Mark Levison 关注 0 他的粉丝 ,译者 曹云飞 关注 0 他的粉丝 发布于 2009年7月27日. 估计阅读时间: 3 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

Jimmy Bogard写了一篇文章:“从你的单元测试中获得价值”,在文章中他给出了三条规则:

  1. “测试名称应该从使用者的角度来描述是什么以及为什么”;核心思想是一名开发者应该能够从测试名称理解测试行为是什么样的。
  2. “测试也是代码,爱他们吧”;仅在产品代码中做重构是不够的。易于理解的测试更易于维护,而且后来的人也更容易弄清楚。 “我憎恨、憎恨长而复杂的测试。如果一个测试的setup方法有30行,请将这些代码放在一个creation方法中。一个长测试会激怒开发者并让其头昏眼花。如果在产品代码中没有长方法,为什么会允许在我们的测试代码中有长方法?”
  3. “不要设定单一fixture的模式/组织风格”;通常情况下是一个类对应一个test fixture,但有时候这样的标准并不适用。

Lior Friedman补充:“规则#0——测试外部行为而不是内部结构。” 或者,测试一个类的期望行为而不是它的目前结构。

Ravichandran Jv补充了他自己的规则:

  1. 尽可能做到每个测试一个断言。
  2. 如果在一个测试中有任何“if else”语句,将语句分支移到单独的测试方法中。
  3. 如果被测试的方法有if else分支,该方法应该被重构。
  4. 测试方法名称应该表明是某种测试。例如,TestMakeReservation与TestMakeNoReservation()是不同的。

NUnit的作者Charlie Poole再次说明:每测试一断言的说法为一个“逻辑断言”,他说:“有时,由于被测试的api缺乏表达能力,你需要写多个断言语句来获得期望的结果。在NUnit框架api的开发中,很多工作就是试图让一个断言做更多的工作。”

Bryan Cook提出了他自己的列表:

  1. 实作:Fixture命名保持一致
  2. 实作:模拟目标代码的命名空间
  3. 实作:Setup/TearDown方法命名保持一致
  4. 考虑:分离测试与产品代码
  5. 实作:按功能给测试命名
  6. 考虑:在期望异常的命名中使用“Cannot”作为前缀

Bryan有超过 一打建议

有很多人推荐Gerard Meszaros的书:“xUnit测试模式:重构测试代码

InfoQ之前与此主题的相关文章:《推荐的TDD教程》,《为可测试性设计》,《来自Google的单元测试技巧》以及《坚持TDD:TDD接受者的问题和解决方案》。

查看英文原文:Guidelines for Better Unit Tests

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

# 如果被测试的方法有if else分支,该方法应该被重构? by 张 晓庆

对这句话持保留态度

写的非常好 by haixiang xu

“测试也是代码,爱他们吧”
“尽可能做到每个测试一个断言”
“测试外部行为而不是内部结构”
写代码时,我们有更多的自由(编程语言);写测试时,我们处于受限的结构(测试框架)。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT