首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >一个完整的TDD演练案例(三)

一个完整的TDD演练案例(三)

作者头像
张逸
发布2018-10-24 11:10:39
8560
发布2018-10-24 11:10:39
举报
文章被收录于专栏:斑斓斑斓

说明:本讲义是我在ThoughtWorks作为咨询师时,为客户开展TDD Code Kata而编写。案例为Guess Number,案例需求来自当时的同事王瑜珩。当时,我们共同在ThoughtWorks的Zynx交付团队,为培养团队TDD能力进行训练时,引入了本案例。讲义中给出的代码问题则来自客户方的受训学员,可谓“真实的代码坏味道”。个人认为TDD不只是开发方法,还应该是设计方法,因此讲义中包含了诸多设计原理、思想和原则。

目标收益

  • 熟悉IDE快捷键;
  • 掌握TDD基本知识;
  • 识别代码坏味道,熟练运用重构手法;
  • 熟悉JUnit与Mockito框架;
  • 了解Google Guice框架;

我们对Guess Number分解的任务为:

  • 随机生成答案
  • 判断每次猜测的结果
  • 检查输入是否合法
  • 记录并显示历史猜测数据
  • 判断游戏结果。判断猜测次数,如果满6次但是未猜对则判负;如果在6次内猜测的4个数字值与位置都正确,则判胜

开始第三个任务

之所以将“验证输入是否合法”放在第三个任务,是因为它不属于happy path的范畴。它属于辅助业务,重要性相对次之。

提示:对于第三个任务,可以采用Specification By Example的方式来考虑测试用例。

问题:参数 vs. 字段

学员在定义执行该任务的类时,一种可能性是将输入的答案作为类的构造函数参数。例如:

new InputValidator("1 2 3 5").validate();

存在两个错误:

  • 错误地判断了输入值的生命周期。什么内容应该放在构造函数中作为参数?换言之,构造函数参数与对象之间的关系是什么?之所以要作为构造函数参数,就是意味着在某种场景下这些参数值应该在创建该对象时就存在。这些参数值与对象“生死与共”,它们的生命周期是保持一致的。如果不是,就不应该作为构造函数的参数。你觉得输入应该作为构造函数吗?如果我要验证另一条输入应该怎么办?再创建一个InputValidator对象吗?
  • 违反了阅读直觉。validate()方法验证谁?验证空吗?显然这样的接口违反了主-谓-宾的语法。

问题:封装的Answer与输入

既然已经封装了Answer对象,为何validate()方法还是要接收字符串类型的输入?阅读需求,已可寻求到答案。

问题:引入InputValidator类型是否有必要?

多数人会认为这里的验证逻辑与Answer相关,根据前面提到的“信息专家模式”,似乎应该将验证逻辑放到Answer中。然而,这里的需求明确地表示了,如果输入不符合要求,就不允许创建该Answer,而是抛出异常。所以,这里的部分验证逻辑是在创建Answer之前就应该存在,当然就不应该由Answer承担了。

针对第三个任务,验证结果的逻辑不应该由boolean型或错误码来表现。对于表达一种错误规则来说,如果你将其看做是一种业务规则,最好的表达方式是采用自定义异常,除非这门语言允许返回两个值(例如Go语言支持返回多个字,但并不支持异常)。对此,在第二个任务中已有描述,这里不再赘述。

重构:Answer的验证逻辑

在开发第二个任务时,我们已经在Answer类中定义了validate()方法。现在,InputValidator类又提供了validate()方法,且其中部分逻辑是相同的。在实现时,应该如何重构现有代码?

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-10-10,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 逸言 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 目标收益
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档