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 其实描述得更全面。