TDD（测试驱动设计）的项目实践—

TDD-PRACTICE

背景

TDD：测试驱动设计，各种理论，各种优劣，网上有很多的文章来介绍，但是怎么做TDD，从何处开始？会遇到什么问题？怎么解决？OK，PI君也是刚接触TDD没多久，理论不多说，直接从一个小项目开始。

项目需求

① 一个足球比赛类小游戏，用户可以通过键盘操控控球球员前进/后退/左转/右转/加速/传球/射门；如果用户控制的球队没有球权，则用户可以切换控制球员进行铲球/防守；用户可以控制游戏开始，设置游戏时间，一般有两支球队进行比赛；

② 每个球队有一个教练，有十一个球员，有自己的球队队形，用户可以自己调整针对特定队形的球员站位，有自己的队服/队徽；

③ 有一个管理员账号，管理员可以管理球队相关数据，包括球员数据/教练数据/队形数据/队服数据/队徽数据。

需求分析

根据需求确定UseCase，尽可能使用代码描述UseCase。

UseCase-One:Play football game

① 一个足球比赛类小游戏，用户可以通过键盘操控控球球员前进/后退/左转/右转/加速/传球/射门；如果用户控制的球队没有球权，则用户可以切换控制球员进行铲球/防守；用户可以控制游戏开始，设置游戏时间，一般有两支球队进行比赛；

Pi君把需求①进行逐句分析如下：

Step-One：

一个足球比赛类小游戏，有两个球队进行比赛，用户可以控制比赛开始，暂停和结束，Code 描述如下：

FootballTeam teamA=newFootballTeam(); //新建一个球队A

FootballTeam teamB=newFootballTeam(); //新建一个球队B

~~FootballGame newGame=newFootballGame(team_A, team_B);~~ //新建一个游戏，并用A和B球队初始化该游戏

newGame.Start(); //开始游戏

newGame.Pause(); //暂停游戏

newGame.GameOver(); //结束游戏

注：文中的代码都是在新建的单元测试里进行编写，其中涉及到的FootballTeam等类型，实际上并不存在，Pi君就是通过代码把UseCase建立起来，然后确定有哪些类型需要创建，每一个类型又有哪些方法/成员等等，这些都是TDD的理论基础，不熟悉的看官直接Google吧。Pi君在此就不啰嗦了。

注：代码中有特殊标记的部分都是后续可能会引用分析，并进行修改的部分，暂时可以忽略其效果。

注：文中Pi君给出的是C#版本的代码，但是有关TDD的实践方式是相通的，如需java/python/C++版本，Pi君会根据时间安排进行转换，至于其他语言版本，很遗憾Pi暂时还不擅长。

Step-Two:

每个球队有十一个球员，比赛过程中，当球队具有球权时，则用户只能通过键盘控制控球球员进行前进/后退/左转/右转/加速/传球/射门的动作；当球队失去球权时，用户可以切换受控制的球员，在切换过程中，选取用户控制球队距离足球最近的球员。

detail step by step:

① 每个球队有十一个球员：

FootballAthlete piAthlete = new FootballAthlete(“Pi君”); //新建一个名字叫做Pi君的球员（类似新建11个球员）

team_A.AddAthlete(piAthlete); //把PI君等11个球员依次添加至球队A中

② 比赛过程中，当球队具有球权时：

//“球权”是比赛过程中的一种状态属性：teamA或teamB

newGame.BallRightTeam= teamA; //球队A具有球权

newGame.BallRightTeam= teamB; //球队A失去球权，球队B获得球权

当然，也有建议可以把“球权”作为球队的一个属性，类似teamA.HaveBall = true来描述球队A具有球权，但是这样做需要一个关键的逻辑处理，如果teamA.HaveBall = true，则teamB.HaveBall = false必须同时成立，既然如此，Pi君还是建议把“球权”作为比赛过程中的一个状态属性比较直观，也无须其他的逻辑处理。

③ 当球队具有球权时，用户只能通过键盘控制控球球员进行前进/后退/左转/右转/加速/传球/射门的动作：

“控球球员”是一个动态的概念，随着足球的运动，控制足球的球员也在随之变化，控球球员可以被操控进行各种不同的动作，所以控球球员需要一个独立的类来处理，至于为什么不把“控球”作为球员的一个属性，看官们可以反推，Pi君不赘述。

如果不考虑下一条，代码描述可以这么写：

teamA.ControlAthlete = new ControlAthlete(); //新建球队A的控制球员(球队B格式类似)

teamA.ControlAthlete.SetControlAthlete(piAthlete); //A球队的Pi君为控球球员

public class ControlAthlete //控制球员类

{

private FootballAthlete _selectAthlete; //控制球员

private string _teamType; //所属球队类型

private Key _goKey; //前进键

private Key _backKey; //后退键 ...... 类似包含左转/右转/加速/传球/射门的键

public void SetControlAthlete(FootballAthlete){......} //设置控球球员

public ControlAthlete()

{

/*注册动作键被按下时的响应事件*/

_goKey.DownEvent += goKey_DownEvent;

......

}

}

看官可能会奇怪，为什么不设置“球权”呢，毕竟事件的响应是根据“球权”状态来决定的，想想看，“球权”是比赛的一个属性，并且是一个动态的属性，取值范围固定在球队A和球队B，所以，需要获取“球权”的值，只需要让teamA.ControlAthlete知道newGame的信息就OK了，这样，每次键盘事件响应时，实时判断当前比赛的“球权”，“控球球员”即可做出正确的动作。

怎么让teamA.ControlAthlete知道newGame的信息呢？且看后续分解吧，毕竟这不是一个难点。

④ 当球队失去球权时，用户可以切换受控制的球员，在切换过程中，选取用户控制球队距离足球最近的球员：

基于第③步的分析和代码描述，这一步的需求可以这么描述：“切换受控制的球员”，即重新设置了“控球球员”（注意，这里的球员不一定真实控球的那个球员）

//比赛进行时，必然有且只有一场比赛在进行，所以比赛本身是个单例（单例模式）

//在控制球员类中添加“切换键”及其响应事件

public class ControlAthlete //控制球员类

{

private FootballAthlete _selectAthlete; //控制球员

private SwitchKey _switchKey; //切换球员按键

public ControlAthlete()

{

this._switchKey.KeyDown += switchKey_KeyDown;

}

//参数暂时不用定义

private void switchKey_KeyDown(object e, KeyArgs args)

{

//获取当前比赛对象？？？？

~~FootballGame currentGame = new FootballGame();~~

if(currentGame == null)

return;

FootballAthlete nextAthlete = currentGame.GetNeareastAthletefromBall(this._teamType); //获取指定球队举例足球最近的球员

if(nextAthlete == null)

return;

this._selectAthlete = nextAthlete;

RefreshAthleteStatus(); //刷新球员状态（绘制信息）

}

}

出现了一个问题，FootballGame类在“Step-One”中已经存在一个构造函数如下：

FootballGame newGame=newFootballGame(team_A, team_B); //新建一个游戏，并用A和B球队初始化该游戏

而刚刚，FootballGame类还存在另外一个构造函数，如上代码中黑体+斜体+中划线的部分。FootballGame本身是一个单例，也就是内存中始终只有一个该类的实例，并且单例有自己固有的实现方式，之前FootballGame类的两种构造方式显然违反了单例的实现方式，OK，Pi君先给出FootballGame类单例的实现方式：

public class FootballGame

{

private FootballGame(){} //私有化构造函数

private static FootballGame _instance; //唯一实例

public FootballTeam _teamA; //参赛球队A

public FootballTeam _teamB; //参赛球队B

public static FootballGame GetInstance() //获取球队比赛实例

{

if(_instance == null)

_instance = new FootballGame();

return _instance;

}

......

}

扩展：以上代码中加粗的“public”，可能会引起看官们的疑惑，为啥不用属性和私有变量，直接让变量公有，岂不是破坏了类的封装？有违习惯嘛~~其实，这里首先有一个问题需要研究清楚，为什么会有属性的概念，属性带来的好处有哪些？为免离题太远，Pi君只抛出问题，欢迎看官们留言讨论，说说自己的想法，也听一听别人的想法，一起学习，一起进步~

OK，对FootballGame类的实现，意味着需要对之前代码中获取或新建FootballGame对象的部分进行调整和修改。现将修改后的代码展示如下：

FootballGame newGame = FootballGame.GetInstance();//新建一个游戏

newGame._teamA = teamA; //添加球队A参加比赛

newGame._teamB = teamB; //添加球队B参加比赛

FootballGame currentGame = FootballGame.GetInstance(); //获取当前比赛对象

OK，到此，针对UseCase-One的代码描述基本清晰，但是仍然有一些细节的问题没有处理，例如，“控制球员”的每一个动作函数应该怎么编写，其实，这是深入层面需要考虑的问题，感兴趣的看官们可以思考下，Pi君也会在后续给出github上的源码链接。

UseCase-Two:FootballTeam Struct

② 每个球队有一个教练，有十一个球员，有自己的球队队形，用户可以自己调整针对特定队形的球员站位，有自己的队服/队徽；

该条需求直接给出了球队的基本数据结构，So，代码描述如下：

public class FootballTeam

{

private FootballAthlete[11] _athletes; //十一名球员

private TeamFormation _formation; //队形

private FootballTrainer _trainer; //一个足球教练

private string _TShirt; //队服

private string _teamLog; //队徽

}

针对“用户可以自己调整针对特定的球员站位”，又该怎么描述？这是一个需要深挖的需求点，请随Pi君Step by Step：

→如果“站位”只是球员开场时所处的球场位置，那么可以直接将“站位”作为球员自身的属性，这样不但可以知道球员开始的位置，随着比赛的进行，这个位置也会随之变动；

→如果“站位”除了开场时球员所处的球场位置以外，还涵盖球员的频繁跑动区域（防守责任区/进攻战术责任区等），那么“站位”的概念要丰富的多，“站位”可以理解为一种控制规则，球员跑动/传球/防守需要从“站位”中读取规则，然后做出相应的动作;

→既然“站位”的概念被丰富了，那么把“站位”作为球员的属性就变得很勉强，OK，不如把“站位”独立出来，更符合单一职责原则，二者之间的关系是“站位”---->“FootballAthlete”；

→回转查看之前FootballTeam的设计，“private FootballAthlete[11] _athletes; //十一名球员”的存在就显得的多余了，毫不犹豫，先把这一行删除，后续也许有新的需求导致该行的重新恢复，所以，暂时先注释掉该行是个不错的习惯。

OK，现在“队形”被分解为“站位”，“站位”又包括哪些行为或者属性呢？继续Step by Step：

Station oneStation = new Station(); //新建一个“站位”

oneStation.Athlete = piAthlete //把Pi君设置为该“站位”的球员

oneStation.DefendArea.Add(new Point(xxx, yyy)); //添加该“站位”的防守区域

Point startPosition = oneStation.GetStartPos(); //获取当前“站位”的起始位置

teamA._formation.AddStation(oneStation); //将当前“站位”添加至球队“队形”中

现在数据有了，怎么触发行为，行为又是怎么发生呢？继续Step by Step:

//带球跑动的球员是否会触发对方球员的防守行为？

这个问题的回答是层级性的，可以设想为游戏难度，因为需求没有涉及，理解过程中简单的假设有两种游戏难度：困难/简单，“困难”级别的游戏，这个问题的答案自然是：true，“简单”级别则是false。当然，如果把游戏难度细分为“新手级”/"普通级"/“困难级”/“专家级”/“变态级”，那这个问题就不能简单的使用bool值描述......又是一个新的逻辑处理块，但是转念思考，暂时没有这种需求，那就采取最简单的策略：“简单”级别，即答案为false，切记不可过度设计，这是TDD最给力的地方。

当然，如果是用户控制球员防守，那就另当别论了。

//球员的无球跑动？

无球跑动，理解为责任区内的晃动，及脱离“控制球员”的球员“发现”自己不在责任区内时的自动修正跑动。可以放在“RefreshAthleteStatus(); //刷新球员状态（绘制信息）”中添加处理逻辑，不赘述。

OK，到此有关UseCase-Two:FootballTeam Struct的基本结构已经清晰。

UseCase-Three:DataManager

③ 有一个管理员账号，管理员可以管理球队相关数据，包括球员数据/教练数据/队形数据/队服数据/队徽数据。

这是一个典型的数据管理员模块，这部分其实谈不上TDD，有很多现有的框架可以使用，核心是数据库的设计，Pi君不再赘述。

总结

到此，有关足球小游戏的代码逻辑基本清晰，总结来看，我们需要实现的核心类有：

public class FootballGame{......} //足球比赛，这是一个单例

public class FootballTeam{......} //球队

public class FootballAthlete{......} //球员

public class ControlAthlete{......} //控制球员

public class TeamFormation{......} //队形

public class Station{......} //站位

他们之间的关系如下：