### [测试驱动 vs. 测试优先](https://lingcoder.gitee.io/onjava8/#/book/16-Validating-Your-Code?id=%e6%b5%8b%e8%af%95%e9%a9%b1%e5%8a%a8-vs-%e6%b5%8b%e8%af%95%e4%bc%98%e5%85%88) 虽然我自己还没有达到测试优先的意识水平，但我最感兴趣的是来自测试优先中的“测试失败的书签”这一概念。 当你离开你的工作一段时间后，重新回到工作进展中，甚至找到你离开时工作到的地方有时会很有挑战性。 然而，以失败的测试为书签能让你找到之前停止的地方。 这似乎让你能更轻松地暂时离开你的工作，因为不用担心找不到工作进展的位置。 纯粹的测试优先编程的主要问题是它假设你事先了解了你正在解决的问题。 根据我自己的经验，我通常是从实验开始，而只有当我处理问题一段时间后，我对它的理解才会达到能给它编写测试的程度。 当然，偶尔会有一些问题在你开始之前就已经完全定义，但我个人并不常遇到这些问题。 实际上，可能用“*面向测试的开发*(*Test-Oriented Development*)”这个短语来描述编写测试良好的代码或许更好。