提示66-70 为编码测试

今天学习为编码测试相关的内容，还是先看提示：

提示66 测试与找 Bug 无关。

提示67 测试是代码的第一个用户。

提示68 既非自上而下，也不自下而上，基于端对端构建。

提示69 为测试做设计。

提示70 要对软件做测试，否则只能留给用户去做。

作者认为测试与找Bug无关，我们需要的是考虑测试的思维。他还举例说一个写了三十多年测试的程序员不写测试以后发现对代码影响不大，就是他已经养成了思考测试的习惯，但是当他和他人共享代码的时候还是会编写测试，因为测试是开发人员交流的一种方式。

作者还详细介绍了测试驱动开发（TTD）的步骤，通过非常短的循环周期来保证我们一点点前进。但是作者认为这样自下而上的设计并不是最佳方案。同样，自上而下的方式也不行，他认为构建软件的唯一方法是增量式的。构建端到端功能的小块，一边工作一边了解问题。

在聊到为测试做设计时，作者说可以开一扇测试窗口，通过日志文件或者是“热键”组合或魔术 URL来诊断系统。一般而言，你可以留一个特性开关，为特定用户或用户组启用额外的诊断信息。我们系统就是这么做的，既有关键位置的日志文件，又有特定权限的帮助页面。我感觉这些都是一个系统必不可少的组成部分，能够有效帮助我们定位系统的问题。

最糟糕的做法基本可以统称为“以后再测”。开什么玩笑，“以后再测”实际上意味着“永不测试”。

测试、设计、编码——都是在编程。

那些跟自己说以后再补的测试基本都是从来不补，总有人要去测试系统，不是开发人员的话那就是客户。与其让客户发现问题再火急火燎地上TT补救，不如趁早发现问题，把所有隐患都消灭在襁褓中。