在向开发人员介绍单元测试或TDD等工程实践时，往往可以听到这样的疑问。比如：
自己写的程序，自己无法从另一个角度测出问题。
写bug的时间都不够了，哪有时间来写测试？
开发来写测试了，测试干什么？
除了核心代码，没有什么值得测试的。
……
本篇想要通过探讨这些问题背后的困难，来说明程序员怎样通过编写自测代码更有效率的进行开发。
一个例子
首先我们看一个例子。
全项目 的测试
不止一次，我在各种项目中看到这样的测试，往往这也是整个工程中 一个测试。
可以看出，开发者认为编写是有必要的。所以按照“标准”的做法建立了测试目录，引入JUnit依赖。并且利用它在开发的初期来验证某些技术疑问，一般是某些当时还不熟悉的第三方库，或者数据库、中间件等外部依赖。
项目初期技术调研阶段很快过去后，似乎没有更多需要验证的问题。因而也就再没有需要编写测试的地方。
简单而言：“写测试是应该，但我们的代码没什么好测的”
测试，不仅仅关于未知
说起测试，往往与未知相关联。我们通过测试、调试、检测来获取反馈，不断调整。
以上图为例，一般想到的测试，都集中在“已知的未知”这个象限。正如前面的示例代码，使用不熟悉的库带来未知。程序员通过在测试中调用和观察结果来消除未知。
然而，对于自动化测试来说，其实
