到这里。这个游戏的基本功能算做完了。做的比较简单。测试和产品代码也比较随意。
　　大家也可以试着做一做。感受感受测试驱动产品代码。
　　运行效果

　　下面是我在实践TDD中遇到的一些问题、以及我个人对它们的理解。
　　（1）先写测试在写代码开发速度降低了。
　　开发前期速度确实很慢。当项目越来越大。越来越复杂的时候。改一个bug，或者修改story之后。如何确保产品代码是否正确。手动测试需要多少时间呢？或者调试的时间有多长呢？有了这些测试。可以大限度的节省你的时间。也许跑一遍测试可以定位BUG。测试过了。你的修改也没问题了。
　　（2）TDD驱动出来的代码。维护性、扩展性如何。
　　TDD有益于设计。把一个复杂的需求拆分成若干个小模块的过程当中，其实在思考设计。如何保证每个小模块的职责单一。
　　（3）后写测试可以不？
　　我的理解是：第一 测试驱动开发是通过测试去驱动产品代码的，如果遇到一个很难的模块（你写不出来的），可以通过测试一点点的去驱动。第二 如果在开发之后写测试的话，问问自己，会写吗？或者是能写全吗？如果有足够的信心。也可以写。
　　（4）TDD的产物可以方便后期的测试。
　　试想一下，项目到了后期，在庞大的系统面前，我们要修改某个类、某个方法、修改某个BUG、添加或扩展某个功能的时候。是不感觉特没安全感？会不会为了去找由修改一个小功能而导致其他功能崩溃的原因而抓狂呢？会不会为了定位一个BUG而在各个类之间不断的徘徊呢？会不会感觉到牵一发动全身的感觉呢？软件的坏味等等都会导致这种问题出现。到时候不但被老板骂，还要加班！还要陷入无止尽的各种调试中。(主要的是你把TEAM里的MM给连累了！)。想避免这种问题吗？想尽快定位BUG的位置吗？如果你想！
　　说点体会：
　　（1）清晰的测试方法命名，让我们省去了文档维护的时间。
　　（2）站在不同角度分析用户需求。拆分Story有益于你的设计（DI）。
　　（3）所有TDD留下来的测试。可用来做自动化测试，无论你是修BUG，或者添功能。都可以通过自动化测试，快速得到反馈。
　　（4）有了重构的保证。
　　（5）进度可视化。可以看出一个复杂的模块，自己完成了多少。（有多少CASE通过）。
　　（6）小范围迭代。把当前工作重心放在当前这个“小步”上。
　　需要注意的：
　　（1）把握好测试的粒度。
　　（2）测试要尽可能的简单。
　　（3）测试不要依赖可变。
　　（4）断言优先。
　　其实TDD真正有威力的地方是Story划分。以及复杂模块代码的驱动。
　　以后如果有机会。能理解的更深。会把这两个写出来与大家分享分享。
　　对这段时间的TDD做个小总结。TDD的范围比较广。而且也比较抽象。以后会加深对TDD的理解。也会把这些记录下来。
　　代码比较简单。没源码！