1.1 名词定义
SUT 被测试系统 System Under Test（或者CUT，也就是被测试的东西）
TDD 测试驱动开发 Test-Driven Development
1.2 理解单元测试
工作单元是一个什么样的存在？如果按照字面意思来看，单元测试是一个小的部分，也就是一个单元，但这个单元又有着不同的范围，它可以是一个方法，可以是一个类，甚至可以是多个类，一整个组件，当然这种时候都已经不能算是纯粹意义上的单元测试了。
在《单元测试的艺术》中，认为被测试的单元不能尽可能的小。如果单元测试尽可能小，我们可以对每个方法，每个类进行单元测试，但是这样会发现我们需要伪造很多的数据，很多的中间状态，用以支撑我们的单元测试。但是这就有些做无用功了。
一个单元测试，目的在于调用一个工作单元，并且检验这个单元的具体最终结果，如果关于这个最终结果的假设是错误的，那这个单元测试就失败了。这个比较好理解，也就是我们想要失败或者成功，都需要最后的结果与预期相符合，才算成功的单元测试。
1.3 优秀的单元测试
单元测试从本质上来说也是代码，既然是代码，我们当然要编写优秀的代码。优秀的单元测试要有几个特点：
- 自动化可重复执行（需要计算机能自己动手，不需要人工参与）
- 容易实现
- 结果稳定（每次运行相同的测试得到的应该是相同结果）
- 任何人都能一键运行
- 运行速度很快
- 完全控制被测试的部分
- 完全隔离（独立于其他测试）
- 能通过失败发现问题所在
- 在第二天（之后）还能有存在的意义
如果我代码中使用了当前时间，那我每次运行的时候时间都不一样，每次也就不是同一个测试，也就不稳定了， 也就不能算单元测试。诸如此类。
1.4 集成测试和单元测试
思考几个问题：
- 两周前写的一个单元测试，今天还能运行并得到结果吗？
- 两个月前的单元测试，团队中的其他人能运行并得到结果吗？
- 能几分钟跑完全部的单元测试吗？
- 能一键运行全部单元测试吗？
- 能几分钟就写出一个单元测试吗？
这几个问题关注的，都只在于一个单元上的测试结果，集成测试无法做到这些，它更多的依赖于真实的产品环境，而单元测试把被测试的单元和其依赖物分隔开，以保证它能稳定和高效，还能轻易控制和模拟被测试单元的任何行为。
单元测试的具体定义：一个单元测试是一段自动化的代码，这段代码调用被测试的工作单元，之后对这个单元的单个最终结果的某些假设进行检验。单元测试几乎都是用单元测试框架编写的。单元测试很容易编写，能快速运行。单元测试可靠，可读，并且可维护。只要产品代码不发生变化，单元测试的结果就是稳定的。
1.5 扩展–测试驱动开发
TDD的运行逻辑在于，你需要先编写一个会失败的测试，然后创建产品代码，这个产品代码的目的就是让这个测试通过，接下来是重构代码或者创建另一个会失败的测试。TDD的技术核心就在于编写一个会失败的测试以证明产品中代码或者功能的缺失，编写符合测试预期的代码使产品测试通过，以及重构代码。TDD的要求在于，你预期的成功与失败，都必须要在最后得到相同结论，不然一定是你的测试或者你的产品代码出现了问题。TDD要求你能知道如何编写优秀的测试，在编码前编写测试，以及良好的测试设计。