实践TDD的点滴——前置条件的准备一支函数多个前置条件，由于逻辑代码是顺序编写的，这些条件如果分开测试，就
实践TDD的点滴——前置条件的准备
一支函数多个前置条件，由于逻辑代码是顺序编写的，这些条件如果分开测试，就存在第二条件测试时，就要确保让第一个条件成立（哪怕用MOCK方式都很烦），第四个条件需要前面三个条件成立，前置条件越多就越烦，如何解决这个问题。
例：玩家进入游戏世界的逻辑。
(C++的语法，我尽量简化写，大家应该看得懂)
１、如果游戏世界人数超过1000，则进入失败。
２、如果playerName未找到，也就是没有创建过该player，则进入失败。
３、如果player所在的场景之前未添加到gameWorld，则进入失败。
４、如果该player已经进入游戏世界，则进入失败。
对应的类和成员函数简略为：
class GameWorldMock : public GameWorld{protected: virtual bool isPlayerIn(String playerName) { return true; }}; 这种写法较第二种好一些，同时也驱动extract method，但同样也存在不妥的地方。isPlayerIn在实际代码中并没有用到，应该是private的，但为了让测试代码mock，要改成是protected。当然你会说isPlayerIn开放成public都行，正好可以做为enterPlayer的后置检测条件。这里我同样有一个困惑，测试中的后置检测条件往往需要通过一些get函数来提供，但常只在测试代码中才用到，实际代码中并没人调用。类似这样的检测函数很多，如果都public了，类的接口定义就很庞大。我一直提倡类的public函数越少越好，不必要的尽量不提供，这样调用者更容易调用。
其实不只是多个前置条件会遇到这个问题，很多添加、删除功能更是会遇到这个问题。删除一个对象的逻辑，就要求完成添加的所有准备，结果添加部分的代码被重复的测试。我的项目中，很从团队成员都干脆将所有测试写在一起，从添加到中间逻辑再到删除。结果一个测试上百行，不易读，不易修护。
1 楼 windflawlyq 2010-04-09 发现讨论TDD实践的人很少，也许大家认为TDD是引入的难度很低，但对我来说，实践中遇到了很多问题，我相信很多真正实践过的人也会有所体会，如果没有形成对一整套的应对方法和取舍认识，那TDD很难持续下去。 2 楼 lihuachuan 2010-04-12 和楼主有同样的问题
我觉得对成员变量playerExists的访问，在那个类中应该有一个方法如setPlayers(String[])或者addPlayer(String),用来组playerExists赋值
（因为我们一般会把数据存在数据库，所以取\操作数据的代码应该放入另一个类）
那么就可以解决数据的访问
如果这个类是自己解决数据存取的话，那么就要初使化数据库了，如用DBUnit来做
那如果真的遇到数据不与外部交互的话，那就不知道怎么做了
3 楼 windflawlyq 2010-04-20 lihuachuan 写道我觉得对成员变量playerExists的访问，在那个类中应该有一个方法如setPlayers(String[])或者addPlayer(String),用来组playerExists赋值
的确，我有时候会添加一支类似的addPlayers，然后在enterPlayer的所有条件成功时，实现添加的逻辑。这支函数设为private（不应该public），我测试类再以friend的方式（我用c++）直接调用addPlayer来准备进入的玩家数据。
所幸，我现在是开发游戏，不是开发数据库应用（我曾经也开发过好几年），游戏开发用起OO不象数据库那样多麻烦 4 楼 piao_bo_yi 2010-12-31 windflawlyq 写道lihuachuan 写道我觉得对成员变量playerExists的访问，在那个类中应该有一个方法如setPlayers(String[])或者addPlayer(String),用来组playerExists赋值
的确，我有时候会添加一支类似的addPlayers，然后在enterPlayer的所有条件成功时，实现添加的逻辑。这支函数设为private（不应该public），我测试类再以friend的方式（我用c++）直接调用addPlayer来准备进入的玩家数据。
所幸，我现在是开发游戏，不是开发数据库应用（我曾经也开发过好几年），游戏开发用起OO不象数据库那样多麻烦
#ifdef _TEST
define private public
#endif
