测试代码首先也是代码的一种，所以理论上可以用于代码的质量标准也可以全部用于测试代码上。所以好的测试，首先也得是好质量的代码。作者第一个提到的标准是就是代码的可读性。
说到可读性（以下主要结合我的理解而未必全是书里的内容），这是一个和人的认知规律相关的问题。如果人的理解能力和一些天才一样强大，或者代码不是交给人去维护的，那也无所谓什么可读性。但是普通人对于结构和逻辑的理解能力是有限的，即使经过训练也无法提高太多。其中最重要的一个限制，就是人脑的临时存储能力是有限的，简单说来人无法同时记住很多东西，总是记住后面的忘了前面的，如果把人脑比作一个栈的话，这个栈的深度是很有限的（这也是为什么代码条件嵌套的层次越多，对人而言理解就越困难）。为了解决人脑的这个限制，大脑会使用一种重要的技巧，就是抽象。通过抽象，我们可以把同一层次大脑要处理的对象数量控制在一个可以理解的范围之内。这样，一个复杂概念或逻辑就变成了一棵树，这个树每一个node所连接的概念数量是在大脑可以理解的范围之内，这个树的相同深度的节点集合就是一个抽象层次。
说了半天大脑，我们回到代码可读性的问题上。代码可以按照block, 方法，对象，文件，目录，包，库之类分成不同的抽象层次，组成相应的结构，当代码的结构和人脑的概念模型相符合的时候，这个代码的可读性就是好的。反之就是不好的。也就是说可读性好的代码可以很好得把人的概念模型（conceptual model）映射到代码结构（code structure)。反之两者不一致的代码可读性就很差，看了令人想翻桌子。当然喽，人有不同的思维方式，相同的问题可以建立不同的概念模型，有时候看不懂不能简单得说可读性不好，也可能是思考方式不同（不能看不懂就骂人，可能只是没有理解而已，理解了说不定拍手称妙，思维上了一个层次，这也是为什么我们需要学习设计模式之类的概念模型，设计模式就是一种概念模型到代码结构的映射）。但是，在绝大多数情况下，我们不得不承认人的思维方式是有共性的。
坏的可读性会造成一种恶性循环，坏的可读性一般意味着代码的结构就有问题，那么这样的代码将很难修改，一改动很容易产生错误，让人越来越不敢去碰，一碰就要花很多时间，而且在坏的结构上修修补补导致代码结构越来越脆弱。
好的代码可读性意味着好的代码结构。好的测试代码结构要达到的目的，就是要能通过合理的结构展示自己所测试的程序功能。极端差的例子就是整个系统只有一个测试，这个测试测了系统所有功能。我们如何去改进这样一个测试？我们要拆分它，如何拆分才好，这就是对结构的要求。这里只讲为何可读性是好的测试非常重要的指标，至于如何能达到好的可读性（本书其实是从反面讲的，讲的是坏的可读性的smell以及如何改进），书后面将会介绍。
