08｜TDD中的驱动（1）：驱动的极限是什么？
测试驱动开发的核心要点：单元级别功能测试能够驱动其对应单元（功能上下文或变化点）的外在功能需求。而对于对应单元之内功能的实现，测试就没有办法了。
[图片上传失败...(image-151407-1674484392920)]
比如上面演示的视频中，Args.parse 是一个大的功能上下文。按照我们的实现思路，我们将它分解成了一个小的功能上下文：将参数列表分解为映射。那么我们可以将参数列表分解放入另外一个单元（Args.toMap)，对它进行测试，从而驱动它的实现。
也就是说，单元级别功能测试无法驱动小于其测试单元的功能需求，也无法驱动单元内的实现方式，需要进一步拆分功能上下文才可以。而指引功能上下文拆分的方式有很多，比如有不同的实现思路、架构等。
TDD 的极限
曾经有些人希望通过构造难以用测试驱动出实现的需求，来证明 TDD 不是一种有效的开发方法。对于这些人，我都懒得回应。
第一，是因为这样的需求一点儿都不难构造；
第二，TDD 并没有宣称它是所有开发问题的答案，所以找到一个反例又能说明什么呢？
第三，TDD 的效用在于将研发过程工程化。
那么无法通过 TDD 有效实现需求，也只意味着这类问题不能有效工程化而已。排除一个错误答案，并不代表能找到正确的答案。
测试驱动开发的主要关注点在于功能在单元（模块）间的分配，而对于模块内怎么实现，需要你有自己的想法。
当然 Kent Beck 说得更直接：TDD 可以提高效率，但不能避免愚蠢。
小结
测试驱动开发到底驱动了什么：功能在单元（模块）间的分配。我们也讲了，测试驱动开发在什么地方会失去驱动力：单元（模块）内的实现方式。
那么很有意思的事就来了，从“驱动”的角度来说，TDD 实际上并不是一种编码技术（Coding Technique），它无法帮助实现你不会写的代码，你必须要知道如何实现这些功能；但是一旦你明确了要实现的功能，并且知道要怎么实现，TDD 可以帮助你更好地将功能放置到不同的单元。
也就是说，TDD“驱动”的是架构，因而实际是一种架构技术。是的，这正是我们讲的编码架构师（Coding Architect），也是真正的实干型而非 PPT 型架构师（当然你可以省略地讲，这是真正的架构师）。这也是为什么 TDD 也被看作 Test Driven Design。当然，我觉得 Test Driven Development 其实描述得更全面。
