测试驱动学习模式
学习本身也需要学习（Study itself also needs to be studied），而且学习本身的学习，还是一个永不停止的过程，永远也没有个完结。这也恰恰是学习自身学习的特点。
人一生下来就对周围进行探索。迈出一步之前假设落脚之处是平的、凹的、或凸的。如果假设不对，就修改自己的视觉识别代码和步行代码来适应更复杂的环境。这在本质上是测试的思想。当然测试也是一种探索，只是没有其他一些种类探索那样的盲目，是一种目的性比较强的探索。
测试驱动学习模式（Test Driven Study Pattern，TDSP）可以对测试驱动学习模式自身进行学习。测试驱动学习模式的关键之处就是对追根溯源、对所谓终极真理的追求强烈地说不。不然的话，就没办法使用测试驱动学习模式来学习测试驱动学习模式，就会陷入鸡生蛋、蛋生鸡的无限循环反复不能自拔。以下是测试驱动学习模式对鸡生蛋还是蛋生鸡问题的回答：
- 如果喜欢或需要吃蛋（鸡），而只有鸡（蛋）没有蛋（鸡），就养鸡生蛋（孵蛋成鸡）；
- 如果喜欢或需要吃蛋（鸡），并且蛋（鸡）刚好就有，就直接吃；
- 如果喜欢或需要吃蛋（鸡），而蛋（鸡）和鸡（蛋）都没有，那就到其他地方找找。
人不可能什么都喜欢也不可能什么都需要。测试驱动学习模式最适合对未知事物怀有浓烈兴趣且高度敬业的人，也比较适合兴趣和职业精神只占其一的人。但对那些对未知毫无兴趣、又不敬业的人，测试驱动学习模式束手无策。
保持饥饿，保持无知（Stay hungry，stay foolish）。整天打嗝的人即使面对珍馐美味，也毫无食欲，更不要指望其能使用测试驱动学习模式作为猎枪，在寒冷的户外猎取食物。
人都有吃饱的时候，但千万不要让垃圾阻塞肠胃。如何区别垃圾是测试驱动学习模式解决的最漂亮的问题。可以说，使用测试驱动学习模式获得的知识，根本就没有垃圾。既然测试驱动学习模式自身也是由测试驱动学习模式得到，因此可以证明测试驱动学习模式不是垃圾。
测试驱动学习模式典型的思考方式：
本人需要的是什么？
其所有的是什么？
如何使用其所有的来满足本人所需要的？
前两个问题是What类型，后一个问题是How类型的；测试驱动学习模式里没有Why类型的问题，比如没有类似“为什么它的所有满足不了我的需要”这样的问题。
测试驱动学习模式不提倡问以下问题：
某某的本质到底是什么
比如测试驱动学习模式的本质到底是什么？所有以为什么开头的问题
拒绝问为什么的问题会不会导致不求甚解？是的，会导致。但不求甚解在测试驱动学习模式里是难得的好习惯。不求甚解的对象是所有不为本人所需要的。当然也有一些饱食终日的人什么都不需要。这也是测试驱动学习模式对此类人毫无效果的原因。
测试驱动学习模式提倡有清晰的、可验证的观点。哪怕事后证明是错误的观点也比含糊不清要好。有了观点之后马上着手去验证，去实践中测试这个观点。如果经测试这个观点是对的，那可以把这个观点收藏起来；否则可以修正之前的观点，进一步验证；如此循环。
大量的、清晰而且可验证的观点是一笔财富，存的越多测试驱动学习者就越富有。而不清晰不可验证的观点对学习者来说恰恰是类似债务的东西，越多越贫穷；将来要栽的跟头也就越多。
测试驱动学习模式不相信“谦虚使人进步，骄傲使人落后”，而是认为无论骄傲还是谦虚都可以使人进步，只要这人是真诚的。真诚的人更容易提出清晰而可验证的观点，即使一些观点经过验证并不正确，但仍然有益；而虚伪的人，比如一些政治家，提出含糊而不可验证的观点，不到翁一样摇摇摆摆，根本不是为了获取知识，因此也获取不到真正的知识。
如果测试驱动学习者发现自己有很多含糊而不可验证的观点，怎么办？可以肯定的是能有此发现是天大的好事，因为很多人还不知道自己的观点含糊不可验证呢。剩下的任务就简单了，只需使这些观点其变得清晰并可验证就可以了。
一个观点是否含糊也许难于察觉，但其是否可以验证（或容易验证）却是非常容易验证的问题。因此试图验证一个观点是否正确是测试驱动学习模式的第一步，也就是最关键的一步。观点是否正确并不重要，重要的是该观点是否容易验证。
总结一下测试驱动学习模式所强调的：
- 敏捷而直接
先找到学习对象一个最简单的使用方式，在这个最简单使用方式之下用测试的方法体会其功能及使用。 - 把握整体
面向学习对象的主体思想，避免迷失于具体的细节。 - 迅速应用于实践
测试的特点就是实践性强，可以同时从成功和失败中学习，学到的也不仅仅是经验而是规律性的东西。
需要注意的是以上三条总结是否正确需要进一步使用测试驱动学习模式来验证。甚至这三条总结的观点是否清晰可验证都需要读者进一步验证。
测试驱动学习模式有以下好处：
- 学习周期短见效快
即使只是花了很少的时间，学会了很少的一部分知识，也可以很快投入使用。甚至用于用于学习的测试过程经过简单整理，也可以投入实践中进行使用。 - 直指学习对象的可执行核心
直接解决的学习对象的可执行部分是什么，怎么用的问题。避免陷入其不可执行部分的细节争论。 - 拿测试说话沟通容易
测试也能说话，而且测试是注重实践的人之间最精确的语言。使用测试进行交流会避免很多不必要的误解。
需要注意的是这三条好处是否正确需要进一步使用测试驱动学习模式来验证。甚至三条好处的观点是否清晰可验证都需要读者进一步验证。
测试驱动的学习模式特别适合街边的程序员（Programmers on the street）来使用。街边的程序员的称谓来自高德纳（Donald Ervin Knuth），并非贬义，泛指以编程为生计的技术人员。世界上大部分程序员都是街边的程序员。象牙塔里的程序员寥寥无几，其中高德纳就是一个。
街边的程序员还可以分为两类，一类是街右边的程序员，一类是街左边的程序员。街右边的走的路比街左边的多，街左边的比街右边的看的多。测试驱动学习模式认为两边的都应该往中间靠靠。埋头走路的也应该抬头看看，站在街边观看的也应该走走。学习的道路上没有机动车，撞不死；跌倒了爬起来拍拍土也就没事了；相互碰碰身体更强壮，没理由老绕着走。
象牙塔里到底有没有程序员？这个问题并不是很清晰可验证，可以在这个问题变得清晰可验证之前，对其不加理会。因此街边的程序员可以暂时地走在测试驱动学习模式的道路上。
