最近在一个新项目中尝试使用了 TDD 有测试保驾护航是真的爽。事情是这样的，今天经过讨论要把一个模型替换掉，刚听到这个消息的时候我是崩溃的，心想这要是出 bug 怎么办，到转念一想我测试覆盖率 88% 应该还好，动手改完跑起测试，果然不过，但是只是几个叫小问题，再次运行测试 绿灯！我的天，此时内心别提多么舒爽，这要是没有测试我今晚应该不用睡了，谢谢老师。最近也开始先分解任务再小步提交，这么做下来有一种很踏实的感觉，同事 review 代码也舒服很多。

之前在其他领域的里也有介绍负反馈相关单位内容，各个领域之间还是有很多互通之处。软件或者其他系统一直处于熵增的状态，需要持续的保养和维护。不得不感慨大道至简啊

阅读之后有了基本的认知，还需要阅读这方面的相关书籍和实践

好感动哭了

印象最深的几次TDD。
1. 是个CS应用，从服务端拉取数据后，根据不同状态，客户端执行不同逻辑。采用的方法是，将服务端的响应值记录，然后在测试代码里回放，不依赖服务端。修bug时，每个bug就是一个测试，测试代码里直接回放记录的服务端响应。好处是，回归非常快，而且不依赖服务端
2. 上家公司要做HA软件开发，情况很复杂，手工做测试代价很高。正好赶上docker兴起，于是就写了很多“暴力”代码（比如直接kill服务、删除服务等）测试各种场景，只留少数必须用物理机测试的场景交给人工

以前理解的测试驱动开发，我写完测试、代码完成就结束了。看完文章，增加对重构理解。有了测试的依托，改动代码的结果也能从测试结果中看出。
目前对于 TDD 还是处于理解状态，不知道如何真正的在项目工程中使用。因为项目工程往往还有很多其他调用，如rpc，数据库服务，第三方服务，不知道在这个过程如何处理。期待老师的之后文章讲解

以前以为测试驱动开发只是先写测试，再开发就完了。原来还有重构。想想也对。代码第一步完成功能表达，但未经重构的代码必然存在坏味道。重构，才能使代码机构清晰，便于理解阅读

感谢老师指点，之前没听过 TDD，但是知道 Unit Test 很重要，要随着写代码一起写，也没想过原来可以先写 test，后实现 code，这样 test 很自然地时刻存在在开发的每一个阶段。在 TDD 里面 “红——绿——重构” 中，看完老师这边文章对其中的 “红” 和 “绿” 都能理解，因为就是写 code，保证 code 可测并且能够通过所有 test，但是对这里的 “重构” 还是比较地困惑，“重构” 很重要，那么这里有没有什么方向性或者方法可言呢，因为仅仅看 “重构” 的定义，貌似和 test 没有直接的联系，test 只是保证能够更好的 “重构”，文章中只说了 “重构” 是为了消除 “冗余”，消除代码的 “坏味道”，那什么是 “冗余”，什么是 “坏味道”，具体该怎么定义 “重构” 需要解决的问题呢？还有 “重构” 怎样才能更好地执行呢？谢谢老师

测试驱动开发的精髓是第三步重构。最近也是做一个业务测试。发现最初的修改只是通过代码中加特殊的判断去规避了这个问题。在影响性测试中发现，正常的处理逻辑完全满足了这种业务场景。只是我们在当前场景中少置为了一个标记。导致下游不识别。在正常业务流程中增加这个标示完全解决问题。这就是重构的精髓

可测的代码往往符合类的单一原则。

老师，运维写脚本也需要考虑测试吗？

感觉TDD的时候很容易就写成了冰淇淋蛋卷的测试结构，因为不太可能去TDD某个类里的某个方法。而且感觉冰淇淋蛋卷对重构更友好，毕竟测试是端到端的，不在乎内部如何实现。

有时别人写的文档比较模糊时，我会直接看测试用例去了解接口怎么用。

PowerMock框架是可以支持mock static类和方法的

TDD的节奏是：红-绿-重构，先编写一个失败的测试，然后编写一个代码通过测试，最后消除冗余，消除代码的坏味道。写代码前先想想怎么测试，我们必须保证编写可测试的代码。

今天又被作者引入了测试先行的开发理念，一直觉得Tdd不一定要先写测试，完成功能代码再写测试也可以啊，用单元测试去验证写的逻辑，发现测试失败了，回去看代码实现，绿了再回去看代码坏味道。

TDD 还需要事先分析和任务分解，不然就变成为了 TDD 而 TDD 了

TDD，和任务分解可以说是相辅相成。
在写测试的时候，一个一个的case其实在对任务的分解，考虑每个case所要达到的目标，输入、输出，以及case与case之间的衔接。写测试的时候，我们是站在一个consumer的角度来的，考虑的是这个case的输入和输出。首先，这对于设计能力有一定的要求，其次，按照这种方式写出来的代码可用性更高。因为我们的起点是consumer 而不是provider

测试清单可以和DoD联系起来么？