We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
一个完整的TDD演练案例（一） http://bit.ly/2LI8Ks8 我是张逸
<p data-mpa-powered-by="yiban.io"><img data-copyright="0" data-ratio="0.2609375" data-s="300,640" data-src="https://mmbiz.qpic.cn/mmbiz_png/d3Qa7X5fakAD4PTHLDiaqcbFUTRRCJQmQNz8PzqYvwavQ392LdGjje8RXZzFCDtyOTLvb9ibBBCooEk2ibI3YUKIg/640?wx_fmt=png" data-type="png" data-w="640"></p>
标签 | TDD Java
字数 | 3663字
阅读 | 10分钟
说明：本讲义是我在ThoughtWorks作为咨询师时，为客户开展TDD Code Kata而编写。案例为Guess Number，案例需求来自当时的同事王瑜珩。当时，我们共同在ThoughtWorks的Zynx交付团队，为培养团队TDD能力进行训练时，引入了本案例。讲义中给出的代码问题则来自客户方的受训学员，可谓“真实的代码坏味道”。个人认为TDD不只是开发方法，还应该是设计方法，因此讲义中包含了诸多设计原理、思想和原则。
熟悉IDE快捷键；
掌握TDD基本知识；
识别代码坏味道，熟练运用重构手法；
熟悉JUnit与Mockito框架；
了解Google Guice框架；
实现猜数字的游戏。游戏有四个格子，每个格子有一个0到9的数字，任意两个格子的数字都不一样。你有6次猜测的机会，如果猜对则获胜，否则失败。每次猜测时需依序输入4个数字，程序会根据猜测的情况给出xAxB的反馈，A前面的数字代表位置和数字都对的个数，B前面的数字代表数字对但是位置不对的个数。
例如：答案是1 2 3 4， 那么对于不同的输入，有如下的输出：
答案在游戏开始时随机生成。输入只有6次机会，在每次猜测时，程序应给出当前猜测的结果，以及之前所有猜测的数字和结果以供玩家参考。输入界面为控制台（Console），以避免太多与问题无关的界面代码。输入时，用空格分隔数字。
TDD的一个重要步骤是在分析需求之后，对其进行任务分解。每个任务相当于一个功能点，它们都是可以验证的。在进行TDD时，可以根据具体情况，对任务再进行分解，或者增加一些我们之前未曾发现的任务。
我们对Guess Number分解的任务为：
在分解好任务开始测试驱动开发时，我们应该优先选择哪一个任务？ 选择的标准包括：
从依赖的角度看，并不一定需要优先选择前序任务，因为我们可以使用Mock的方式驱动出当前任务需要依赖的接口，而不用考虑实现。例如，“随机生成答案”任务与“判断每次猜测的结果”任务之间存在前后序的依赖关系，但实现的顺序却并不需要按照此顺序。
对于任务的重要性，主要是判断任务是否整个系统（模块）的核心功能。一个判断标准是确定任务是功能的主要流程还是异常流程。例如任务“检查输入是否合法”即为异常流程，可以考虑后做。
我们认为，任务“判断每次的猜测结果”可以作为起始的核心任务。
在进行测试驱动时，选择好任务后，就需要对测试用例进行分析。可以假设该任务就是你要实现的一个完整功能，然后从外部调用的角度去思考用例。这体现为两个方面：
选择测试样本；
驱动承担该职责的对象，根据意图设计接口；
选择测试样本的方法请参考实例化需求。例如，这里可以选择全中或全错等样本。通常情况下，编写的第一个测试应该选择最简单的样本。
由Gojko Adzic的著作Specification By Example（实例化需求），介绍了如何通过实例去分析和沟通需求。它是一组过程模式，可以协助软件产品的变更，确保有效地交付正确的产品。实例化需求的过程分为：
从目标中获取范围
用实例进行描述
精炼需求说明
自动化验证，无须改变需求说明
频繁验证
演进出一个文档系统
更多内容，请参考该书。
注意：单元测试不能针对方法编写测试，而应根据业务编写测试用例。一个测试方法只能做一件事情，代表一个测试样本和一个业务规则。
设计接口是体现测试驱动开发“驱动力”的重要一点。之所以先编写测试，就是希望开发人员站在调用者的角度去思考，即所谓“意图导向编程”。从调用的角度思考，可以驱动我们思考并达到如下目的：
在编写测试方法时，应遵循Given-When-Then模式，这种方式描述了测试的准备，期待的行为，以及相关的验收条件。Given-When-Then模式体现了TDD对设计的驱动力：
编写Given时，“驱动”我们思考被测对象的创建，以及它与其他对象的协作；
编写When时，“驱动”我们思考被测接口的方法命名，以及它需要接收的传入参数；考虑行为方式，究竟是命令式还是查询式方法(CQS原则)；
编写Then时，“驱动”我们分析被测接口的返回值；
CQS原则，即命令-查询分离原则（Command-Query Separation），是指一个函数要么是一个命令来执行动作，要么是一个查询来给调用者返回数据。但是不能两者都是。
对于任务“判断每次的猜测结果”，我们首先要考虑由谁来执行此任务。从面向对象设计的角度来讲，这里的任务即“职责”，我们要找到职责的承担者。从拟人化的角度去思考所谓“对象”，就是要找到能够彻底理解（Understand）该职责的对象。遵循信息专家模式，大多数情况下，承担职责的对象常常是拥有与该职责相关信息的信息持有者，即所谓“信息专家”。
信息专家模式（Information Expert）是GRASP模式中解决类的职责分配问题的最基本的模式。
问题：
当我们为系统发现完对象和职责之后，职责的分配原则（职责将分配给哪个对象执行）是什么？
解决方案：
职责的执行需要某些信息（information），把职责分配给该信息的拥有者。换句话说，某项职责的执行需要某些资源，只有拥有这些资源的对象才有资格执行职责。
优点：
可能的答案：Game，Player，Round
提示：应让学员充分思考承担职责的角色，不能在未经分析之前就开始编写测试，从而忽略测试带来的驱动力，甚至忘记一些基本的命名原则和面向对象设计思想。例如，学员可能会将被测类命名为Guess、Check，而被测方法也被命名为guess()、check()。
Guess
Check
guess()
check()
类命名规则：测试类与被测类的命名应保持一致，通常情况下，测试类的名称为：被测类名称+Test后缀。例如这里的Game类为被测类，则测试类命名为GameTest。
方法命名规则：测试方法应表述业务含义，这样就能使得测试类可以成为文档。测试方法可以足够长，以便于清晰地表述业务。为了更好地辨别方法名表达的含义，ThoughtWorks提倡用Ruby风格的命名方法，即下划线分隔方法的每个单词，而非Java传统的驼峰风格。建议测试方法名以should开头，此时，默认的主语为被测类。例如：
@Test public void should_return_0A0B_when_no_number_guessed_correctly(){ }
这里的方法可以阅读为：Game should return 0A0B when no number guessed correctly。显然，这是一条描述了业务规则的自然语言。
现在编写测试。由于事先已经明确被测类为Game，编写测试的Given部分，让我们思考如何创建Game对象？是否可以简单地创建？
分析任务，需要判断猜测结果，则必然要求获知游戏的答案。这个答案与Game的关系是什么呢？这里产生的驱动力是如何创建Game对象？为了创建该对象，需要提供哪些准备？这使得我们驱动出Answer类的定义。
Answer
学员容易写出的代码，以如下方式表现答案(Answer)：
第一种方式除了缺乏对整数值的限制外，一个问题还在于暴露了实现细节。第二种方式甚至无法对答案的个数进行限制。第三种方式则与输入有关，使得Game类还要承担解析输入字符串的职责，违背了单一职责原则（说明：在后面，我们为Answer类提供了工厂方法，可以将传入的字符串解析为Answer对象，也即是由Answer承担解析输入字符串的职责，这同时也遵循“信息专家模式”。）
我们可以从如何构造一个Answer对象着手，看看该如何定义Answer类。
由Robert Martin提出，该原则指出：就一个类而言，应该只专注于做一件事和仅有一个引起变化的原因。
编写When可以帮助开发者思考类的行为。一定要从业务而非实现的角度去思考接口。例如：
实现角度的设计：check()
业务角度的设计：guess()
注意两个方法命名表达意图的不同。
编写Then实际上是考虑如何验证。没有任何验证的测试不能称其为测试。由于该任务为判断输入答案是否正确，并获得猜测结果，因而必然需要返回值。从需求来看，只需要返回一个形如xAxB的字符串即可。
至少就目前而言，并没有必要。因为从需求来看，仅仅需要返回一个形如xAxB的字符串而言。这是需要遵循简单设计的要求，不必过度设计。
如前所述，任务“判断每次的猜测结果”存在多个测试样本，例如一个都不对，或者全部正确，又或者值正确而位置不正确等，因而需要编写多个测试。在编写第一个测试时，可以简单实现使得测试快速通过，然后随着多个测试的编写，再驱动出检查输入数值的算法。
根据以上的分析，我们编写的第一个测试如下所示，它遵循了Given-When-Then模式：
@Test public void should_return_0A0B_when_no_number_is_correct() { Answer actualAnswer = Answer.createAnswer("1 2 3 4"); Game game = new Game(actualAnswer); Answer inputAnswer = Answer.createAnswer("5 6 7 8"); String result = game.guess(inputAnswer); assertThat(result , is("0A0B")); }
这个测试已经驱动出了Answer的创建，Game类的定义，guess()接口的定义。在保证编译通过后，应该首先运行该测试。此时测试必然是失败的。为了使该测试快速通过，我们可以简单实现guess()方法，例如直接返回“0A0B”字符串。接着，就可以编写第二个测试。
Game
首先，它能够保证测试框架是没有问题的；其次，它可以避免偶然的成功，因为测试通过不等于实现一定是正确的。
❈ 题图来自Mono诗+歌。
</div><br>
The text was updated successfully, but these errors were encountered:
No branches or pull requests
一个完整的TDD演练案例（一）
http://bit.ly/2LI8Ks8
我是张逸
标签 | TDD Java
字数 | 3663字
阅读 | 10分钟
目标收益
熟悉IDE快捷键；
掌握TDD基本知识；
识别代码坏味道，熟练运用重构手法；
熟悉JUnit与Mockito框架；
了解Google Guice框架；
整体需求
实现猜数字的游戏。游戏有四个格子，每个格子有一个0到9的数字，任意两个格子的数字都不一样。你有6次猜测的机会，如果猜对则获胜，否则失败。每次猜测时需依序输入4个数字，程序会根据猜测的情况给出xAxB的反馈，A前面的数字代表位置和数字都对的个数，B前面的数字代表数字对但是位置不对的个数。
例如：答案是1 2 3 4， 那么对于不同的输入，有如下的输出：
答案在游戏开始时随机生成。输入只有6次机会，在每次猜测时，程序应给出当前猜测的结果，以及之前所有猜测的数字和结果以供玩家参考。输入界面为控制台（Console），以避免太多与问题无关的界面代码。输入时，用空格分隔数字。
任务分解
TDD的一个重要步骤是在分析需求之后，对其进行任务分解。每个任务相当于一个功能点，它们都是可以验证的。在进行TDD时，可以根据具体情况，对任务再进行分解，或者增加一些我们之前未曾发现的任务。
练习：分解任务
我们对Guess Number分解的任务为：
讨论：选择开始的任务
在分解好任务开始测试驱动开发时，我们应该优先选择哪一个任务？ 选择的标准包括：
从依赖的角度看，并不一定需要优先选择前序任务，因为我们可以使用Mock的方式驱动出当前任务需要依赖的接口，而不用考虑实现。例如，“随机生成答案”任务与“判断每次猜测的结果”任务之间存在前后序的依赖关系，但实现的顺序却并不需要按照此顺序。
对于任务的重要性，主要是判断任务是否整个系统（模块）的核心功能。一个判断标准是确定任务是功能的主要流程还是异常流程。例如任务“检查输入是否合法”即为异常流程，可以考虑后做。
测试驱动开发
开始第一个任务
我们认为，任务“判断每次的猜测结果”可以作为起始的核心任务。
任务：判断每次的猜测结果
在进行测试驱动时，选择好任务后，就需要对测试用例进行分析。可以假设该任务就是你要实现的一个完整功能，然后从外部调用的角度去思考用例。这体现为两个方面：
选择测试样本；
驱动承担该职责的对象，根据意图设计接口；
选择测试样本的方法请参考实例化需求。例如，这里可以选择全中或全错等样本。通常情况下，编写的第一个测试应该选择最简单的样本。
知识：Specification By Example
由Gojko Adzic的著作Specification By Example（实例化需求），介绍了如何通过实例去分析和沟通需求。它是一组过程模式，可以协助软件产品的变更，确保有效地交付正确的产品。实例化需求的过程分为：
从目标中获取范围
用实例进行描述
精炼需求说明
自动化验证，无须改变需求说明
频繁验证
演进出一个文档系统
更多内容，请参考该书。
注意：单元测试不能针对方法编写测试，而应根据业务编写测试用例。一个测试方法只能做一件事情，代表一个测试样本和一个业务规则。
思考：测试驱动开发的驱动力
设计接口是体现测试驱动开发“驱动力”的重要一点。之所以先编写测试，就是希望开发人员站在调用者的角度去思考，即所谓“意图导向编程”。从调用的角度思考，可以驱动我们思考并达到如下目的：
知识：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后缀。例如这里的Game类为被测类，则测试类命名为GameTest。
方法命名规则：测试方法应表述业务含义，这样就能使得测试类可以成为文档。测试方法可以足够长，以便于清晰地表述业务。为了更好地辨别方法名表达的含义，ThoughtWorks提倡用Ruby风格的命名方法，即下划线分隔方法的每个单词，而非Java传统的驼峰风格。建议测试方法名以should开头，此时，默认的主语为被测类。例如：
这里的方法可以阅读为：Game should return 0A0B when no number guessed correctly。显然，这是一条描述了业务规则的自然语言。
现在编写测试。由于事先已经明确被测类为Game，编写测试的Given部分，让我们思考如何创建Game对象？是否可以简单地创建？
分析任务，需要判断猜测结果，则必然要求获知游戏的答案。这个答案与Game的关系是什么呢？这里产生的驱动力是如何创建Game对象？为了创建该对象，需要提供哪些准备？这使得我们驱动出
Answer类的定义。讨论：由4个数字组成的答案是否需要封装？
学员容易写出的代码，以如下方式表现答案(Answer)：
第一种方式除了缺乏对整数值的限制外，一个问题还在于暴露了实现细节。第二种方式甚至无法对答案的个数进行限制。第三种方式则与输入有关，使得Game类还要承担解析输入字符串的职责，违背了单一职责原则（说明：在后面，我们为Answer类提供了工厂方法，可以将传入的字符串解析为Answer对象，也即是由Answer承担解析输入字符串的职责，这同时也遵循“信息专家模式”。）
思考：Answer的定义
我们可以从如何构造一个Answer对象着手，看看该如何定义
Answer类。知识：单一职责原则
由Robert Martin提出，该原则指出：就一个类而言，应该只专注于做一件事和仅有一个引起变化的原因。
编写When可以帮助开发者思考类的行为。一定要从业务而非实现的角度去思考接口。例如：
实现角度的设计：
check()业务角度的设计：
guess()注意两个方法命名表达意图的不同。
编写Then实际上是考虑如何验证。没有任何验证的测试不能称其为测试。由于该任务为判断输入答案是否正确，并获得猜测结果，因而必然需要返回值。从需求来看，只需要返回一个形如xAxB的字符串即可。
思考：是否需要将猜测结果封装为类？
至少就目前而言，并没有必要。因为从需求来看，仅仅需要返回一个形如xAxB的字符串而言。这是需要遵循简单设计的要求，不必过度设计。
如前所述，任务“判断每次的猜测结果”存在多个测试样本，例如一个都不对，或者全部正确，又或者值正确而位置不正确等，因而需要编写多个测试。在编写第一个测试时，可以简单实现使得测试快速通过，然后随着多个测试的编写，再驱动出检查输入数值的算法。
根据以上的分析，我们编写的第一个测试如下所示，它遵循了Given-When-Then模式：
这个测试已经驱动出了
Answer的创建，Game类的定义，guess()接口的定义。在保证编译通过后，应该首先运行该测试。此时测试必然是失败的。为了使该测试快速通过，我们可以简单实现guess()方法，例如直接返回“0A0B”字符串。接着，就可以编写第二个测试。思考：为何要先运行一个失败的测试？
首先，它能够保证测试框架是没有问题的；其次，它可以避免偶然的成功，因为测试通过不等于实现一定是正确的。
❈ 题图来自Mono诗+歌。
via mp.weixin.qq.com http://bit.ly/17KUbtk
January 2, 2019 at 07:47AM
The text was updated successfully, but these errors were encountered: