我就被误导了。之前总以为一定要按单元测试，设计成严格的解耦，带来的问题就是过多的使用mock技术，导致后来阅读理解测试成本越来越高。现在看完这篇文章很多疑惑一下子就解开了。

05 06 07 课笔记 http://wyyl1.com/post/19/05 状态验证：一波操作后验证返回结果是否和预期一样 行为验证：验证一波操作是否严格按预期的顺序执行，不管结果；对 TDD 用处不大，因为大多数情况下会丧失测试的有效性 ❗️恍然大悟 在测试驱动开发中，从来没有强调必须是“单元测试”。反而在大多数情况下，都是针对不同单元粒度的功能测试。并通过这一系列不同单元粒度的功能测试，驱动软件的开发。 ⭐️ 两位超级大佬说的 Kent Beck：通过构造恰当粒度的黑盒功能测试驱动开发 Martin Folwer：DD 社区所谓的单元测试到底是“能提供快速反馈的低成本的研发测试” Martin Fowler：建议将 TDD 中的测试叫作极限单元测试（Xunit Testing），以区别于行业中的叫法

老师，请问什么叫超过认知负载呢。比如同一段代码逻辑，我一开始可能不太熟悉，觉得它又臭又长看不太懂，但是我看了几遍熟悉了之后，就会觉得这段代码逻辑又比较容易理解了。那这段代码逻辑是超出认知负载还是未超出认知负载呢

我把Test定义为:不同工作单元的功能测试。其中工作单元是指实现某项/些功能，完成某项/些工作的代码集合（类，包，组件等）。

如果TDD是功能測試，而我覺得絕大多數功能是單個單元完不成的，那麼TDD產生的UT數就不會多。而測試金字塔理論最底層佔大多數的是UT，還成立嗎？跟TDD是不是矛盾？

之前看《修改代码的艺术》里面的单元测试，就是指一个类的测试。这种实际上是在测试实现。如果一堆类都有了一个测试，会让我们测试代码和实现绑定死了，从而阻止重构。这点上我觉得TDD的测试更是一种对行为的测试而不是对实现。

老马《单元测试》的中文版：https://www.yuque.com/yuanshenjian/agile/unit-test 篇幅很小，作为下午茶吧~

个人理解TDD其实就是一种结果导向的做事方式，或者叫“以终为始”，再配上8x的任务分解法，把大结果分解成小结果，然后稳步得到每一个小结果后，最终目标也就达成了。借用OKR中的概念的话，过程就变成了：确定 Object (目标)，分解 Key Result (关键结果)，获得关键结果，完成目标。所以，我更愿意把“TDD+任务分解法”叫做 OKRDD（目标分解+关键结果驱动开发）。😝

正如文中所说”毕竟 TDD 中的测试，并不是一种关于测试的技术，而是通过分解功能以驱动软件开发的技术。“。这句才是TDD关注点的核心，而大多数人在谈论TDD的时候都落在单元测试的讨论上去了。 这导致很多还没有接触过TDD的人，都以为重点是单元测试。