亦步亦趋是不对的，有一些具体事情我们是可以做的

1. 我看到有同学写TestCase的时候喜欢使用全局变量，这样做是可以，但是最好使用const modifier，否则，Test case之间会互相影响，甚至各个test cases之间的调用顺序会影响结果，这是很不好的，因为Test cases设计本身不是为了代码优美，是为了确保特定的需求。
2. 继续领会TestDriven的精神。Testcase的设计帮助我们更加全面的思考问题以及解决方案，强迫我们拿时间去思考问题的细节。当碰到一个问题的时候，我们很容易会得出模糊的设计，然后一边细化设计，一边开始编码，同时发现了不合理的地方，开始修改设计。。。这个流程本身并不算错误，特别是XP盛行以来。问题的关键是，我们是不是真的能确保 【【尽可能少】】的在实现的过程中修改设计呢？先设计出测试方案会对这个问题有帮助的，这很类似一种Top-Down的方法学。所以，TestCase是个【【好客户】】，他帮助我们梳理需求，并验证我们的实现。
3. 以前似乎看到过XP和TDD的争议。我觉得他们一点都不矛盾，是互为辅助的关系。XP的根本目的是快速了解需求，快速实现，重构，最后给出好的结果，而TDD的目的是帮助我们快速了解需求，思考实现，可以说TDD会辅助XP，使得其降低重构的代价。
4. 我一直觉得我有这样的特点，就是写程序的时候专心写程序，然后碰到什么事情了（比如出去吃饭），因为不能继续写程序了，所以就仔细思考一下刚才的程序，这时候常常能发现问题，或者更好的设计。也就是说，在写程序的过程中回头思考是有好处的，可是如果让我专心的写程序（没人打扰我，没有事情打扰我），我是不愿意主动停下来的，这是个挺奇怪的现象。TDD部分的帮助我改变了这个习惯，运行TDD的时候我还是可以选择思考一下的，呵呵。
5. 作者提出TDD的一个Case尽可能小，这个显然不一定的。比如我们要写个复杂的算法，显然算法是一个整体，不可能拆解下来分布进行测试，这么做也会影响思路的。所以，结论是明显的，没有规则，只有和实践匹配的方法，只要跟我们的环境合适，Caes的大小和多少是可以自己控制的。
6. 不要再去开会或者做其他事情之前匆忙完成代码，但是这个时候也许我们可以将test case写完。