TDD测试驱动开发︱一个完整的TDD测试驱动开发演练案例
2022-11-06
来源：逸言 我是张逸
何通过实例去分析和沟通需求。它是一组过程模式，可以协助软件产品的变更，确保有效地交付正确的产品。实例化需求的过程分为：
从目标中获取范围
用实例进行描述
精炼需求说明
自动化验证，无须改变需求说明
频繁验证
演进出一个文档系统
更多内容，请参考该书。
注意：单元测试不能针对方法编写测试，而应根据业务编写测试用例。一个测试方法只能做一件事情，代表一个测试样本和一个业务规则。
思考：测试驱动开发的驱动力
设计接口是体现测试驱动开发“驱动力”的重要一点。之所以先编写测试，就是希望开发人员站在调用者的角度去思考，即所谓“意图导向编程”。从调用的角度思考，可以驱动我们思考并达到如下目的：
如何命名被测试类以及方法，才能更好地表达设计者的意图，使得测试具有更好的可读性；
被测对象的创建必须简单，这样才符合测试哲学，从而使得设计具有良好的可测试性；
测试使我们只关注接口，而非实现；
知识：Given-When-Then模式
在编写测试方法时，应遵循Given-When-Then模式，这种方式描述了测试的准备，期待的行为，以及相关的验收条件。Given-When-Then模式体现了TDD对设计的驱动力：
编写Given时，“驱动”我们思考被测对象的创建，以及它与其他对象的协作；
编写When时，“驱动”我们思考被测接口的方法命名，以及它需要接收的传入参数；考虑行为方式，究竟是命令式还是查询式方法(CQS原则)；
编写Then时，“驱动”我们分析被测接口的返回值；
知识：CQS原则
CQS原则，即命令-查询分离原则（Command-Query Separation），是指一个函数要么是一个命令来执行动作，要么是一个查询来给调用者返回数据。但是不能两者都是。
对于任务“判断每次的猜测结果”，我们首先要考虑由谁来执行此任务。从面向对象设计的角度来讲，这里的任务即“职责”，我们要找到职责的承担者。从拟人化的角度去思考所谓“对象”，就是要找到能够彻底理解（Understand）该职责的对象。遵循信息专家模式，大多数情况下，承担职责的对象常常是拥有与该职责相关信息的信息持有者，即所谓“信息专家”。
知识：信息专家模式
信息专家模式（Information Expert）是GRASP模式中解决类的职责分配问题的最基本的模式。
问题：
当我们为系统发现完对象和职责之后，职责的分配原则（职责将分配给哪个对象执行）是什么？
解决方案：
职责的执行需要某些信息（information），把职责分配给该信息的拥有者。换句话说，某项职责的执行需要某些资源，只有拥有这些资源的对象才有资格执行职责。
优点：
信息的拥有者类同时就是信息的操作者类，可以减少不必要的类之间的关联。
各类的职责单一明确，容易理解。
思考：寻找承担职责“判断每次的猜测结果”的对象
可能的答案：Game，Player，Round
提示：应让学员充分思考承担职责的角色，不能在未经分析之前就开始编写测试，从而忽略测试带来的驱动力，甚至忘记一些基本的命名原则和面向对象设计思想。例如，学员可能会将被测类命名为Guess、Check，而被测方法也被命名为guess()、check()。
知识：命名规则
类命名规则：测试类与被测类的命名应保持一致，通常情况下，测试类的名称为：被测类名称+Test后缀。例
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
