我对测试的重视是从接触《测试驱动开发的艺术》这本书开始的，那时我还在做web网站开发。尽管项目没有对测试做要求，但我还是为自己编写的service和servlet加上了单元测试，从那以后我一直受益于测试。
　　测试的好处有很多，这里我总结下我在游戏开发中使用测试所感受到的实在的好处。
　　1、 协同开发时，便于确认到底是谁的错，自己的，还是别人的。
　　我是负责开发游戏服务端，项目初期客户端和服务端都需要编写网络通信组件，解析网络数据包。开始我们经常在数据包上遇到问题，客户端一会说没收到服务端的数据包，一会说数据解析不正确，是不是服务端加密错误了。这个时候需要一种方式证明我没错，是你错了。一种没有什么效果的方法是复查自己的代码，但通常查不出什么错误，因为我在审查代码的时候，心里会有一种自我暗示，说“我的代码不会错的”，所以很难发现错误。查不出错误，会指责是对方错了，这样你来我往，慢慢会发生扯皮的现象。我的方法是，自己模拟客户端发包收包，如果我模拟的客户端可以收到包，我会让客户端程序员来看，他会认可我的代码，重新分析他的代码。有时候测试发现我模拟的客户端也收不到包或收包错误，那么我会认识到这很可能是服务端错了。那么自己会换一种心态去审查代码，这次是“相信自己的代码有错误”，所以会比较容易得发现错误。
　　2、  列出测试清单，驱动开发进程。
　　首先申明，我这里说的“测试驱动”不是《测试驱动开发的艺术》提倡的方式，我觉得我只能说是“半驱动”。在完成游戏的攻击，受击部分时，我使用了“半驱动”法。首先先实现基本的技能基础结构，一边实现思路也跟着一边清晰起来，实现后我才开始着手列出测试清单，测试又推动实现的细化。比如考虑受击过程，我列出如下清单（凭印象写出）：
　　a、 测试受击方处于不同状态时，被不同类型的技能命中后，状态的变化情况
　　b、 测试同时命中多个单位
　　c、 测试一个技能多次命中同一单位，受击方扣血，状态的变化情况
　　d、  测试多个技能同时命中同一单位，受击方的状态变化情况
　　……
　　开发时，可以以测试为目标，逐个功能去开发，比起这个类扩展完了，再去扩展另一个类的方式要高效的多。
　　我现在开发的方式是，先开发，在编写测试，然后通过测试再完善开发，是一个不断迭代的过程。
　　3、  修改之前设计的代码，你能通过测试来保证你的修改没有引入未知的错误。
　　有些较基础的代码，去修改它，可能会牵一发而动全身，如果是很早之前写的代码，你可能会忘记该具体会影响到哪些地方。这时候，运行一遍测试，是好不过的方式了。
　　题外话：《测试驱动开发的艺术》对我影响较大，对大的影响是让我开始重视测试，并让我对测试抱有信心，任何项目都可以引入测试。在维护公司游戏的时候，我向部门总监建议过，我们的游戏要加入单元测试，老大想了想告诉我很难，和我举了一些实际的例子，说这个功能怎么怎么样，怎么可能独立测试呢。如果用公司原来开发的游戏引擎，确实是不可能做单元测试的。但是当我参与到游戏开发中时，我始终有这个信念，一定要做单元测试，于是我对引擎做了诸多改良，在设计功能时也会考虑将来如何测试，所以现在我的游戏引擎是可以支持单元测试的。我想改变来自于信念，首先你要相信自己一定能做到。