AWS-用于在 AWS 上进行构建的工具

传统编码方式 VS TDD 编码方式

传统编码方式

• 需求分析，想不清楚细节，管他呢，先开始写
• 发现需求细节不明确，去跟业务人员确认
• 确认好几次终于写完所有逻辑
• 运行起来测试一下，靠，果然不工作，调试
• 调试好久终于工作了
• 转测试，QA 测出 bug，debug， 打补丁
• 终于，代码可以工作了
• 一看代码烂的像坨屎，不敢动，动了还得手工测试，还得让 QA 测试，还得加班…

TDD 编码方式

• 先分解任务，分离关注点（后面有演示）
• 列 Example，用实例化需求，澄清需求细节
• 写测试，只关注需求，程序的输入输出，不关心中间过程
• 写实现，不考虑别的需求，用最简单的方式满足当前这个小需求即可
• 重构，用手法消除代码里的坏味道
• 写完，手动测试一下，基本没什么问题，有问题补个用例，修复
• 转测试，小问题，补用例，修复
• 代码整洁且用例齐全，信心满满地提交

TDD 的好处

降低开发者负担

通过明确的流程，让我们一次只关注一个点，思维负担更小。

保护网

TDD的好处是覆盖完全的单元测试，对产品代码提供了一个保护网，让我们可以轻松地迎接需求变化或改善代码的设计。
所以如果你的项目需求稳定，一次性做完，后续没有任何改动的话，能享受到 TDD
的好处就比较少了。

提前澄清需求

先写测试可以帮助我们去思考需求，并提前澄清需求细节，而不是代码写到一半才发现不明确的需求。

快速反馈

有很多人说TDD时，我的代码量增加了，所以开发效率降低了。但是，如果没有单元测试，你就要手工测试，你要花很多时间去准备数据，启动应用，跳转界面等，反馈是很慢的。准确说，快速反馈是单元测试的好处。

TDD 理论指导（当前不一定能对自身应用）

TDD 的规则

在 TDD 的过程中，需要遵循两条简单的规则：

• 仅在自动测试失败时才编写新代码。
• 消除重复设计（去除不必要的依赖关系），优化设计结构（逐渐使代码一般化）。

第一条规则的言下之意是每次只编写刚刚好使测试通过的代码，并且只在测试运行失败的时候才编写新的代码，因为每次增加的代码少，即使有问题定位起来也非常快，确保我们可以遵循小步快跑的节奏；第二条规则就是让小步快跑更加踏实，在自动化测试的支撑下，通过重构环节消除代码的坏味道来避免代码日渐腐烂，为接下来编码打造一个舒适的环境。
关注点分离是这两条规则隐含的另一个非常重要的原则。其表达的含义指在编码阶段先达到代码“可用”的目标，在重构阶段再追求“简洁”目标，每次只关注一件事！！！

采用 TDD 的动机（感同身受）

控制编程过程中的忧虑感。

有一个有趣的想象，当我感觉压力越大，自身就越不想去做足够多的测试。当知道自己做的测试不够时，就会增加自身的压力，因为我担心自己写的代码有 BUG，对自己编写的代码不够自信，
这是一种心态上的变化。此时测试是开发人员的试金石，可以将对压力的恐惧变为平日的琐事，采用自动化测试，就有机会选择恐惧的程度。

把控编程过程中的反馈与决策之间的差距。

如果我做了一周的规划，并且量化成一个个可操作的任务写到 to-do
list，然后使用测试驱动编码，把完成的任务像这样划掉，那么我的工作目标将变得非常清晰，因为我明确工期，
明确待办事项，明确难点，可以在持续细微的反馈中有意识地做一些适当的调整，比如添加新的任务，删除冗余的测试；还有一点更加让人振奋，我可以知道我大概什么时候可以完工。
项目经理对软件开发进度可以更精确的把握。

TDD 自身实践

1. 设计之初确定系统入口，编写总的入口测试

系统入口测试数据需要尽可能自动化

使用断言确定输出符合预期

使用repo数据进行测试（而不是MOCK），使用后执行删除

2. 对于流程建模Step，为有风险的Step编写测试，Step做到测试覆盖

Step流程全覆盖，从底向上进行集成，确保流程无误

Step全覆盖能够睡得安心

3. 对于Step中使用的Helper等工具类进行测试

工具类最容易出现预期不符的行为

工具类应该在设计之初就编写测试，避免工具类导致的数据不统一

4. 领域对象建模

对于对象建模，对充血方法进行测试自动化

总结

TDD并不是万能的，但是TDD也不是一无是处的，重要的是用方法论的人，引入某同事一句话：

站在教学的角度来讲，我还是很推崇TDD的，TDD是一个很好的思维框架，如果非要教人一个思维框架的话就得教TDD，
不然人会瞎碰，不思考，不总结，不结果导向，靠灵感编程，凭直觉设计，撞大运修bug。最糟糕的是因为没有好的习惯
会接二连三的发生灵异现象。同一道题，习惯不好的人做，总能做出无数种新问题来。而且问题套问题，给他解决要浪费
我半天时间，如果他学会了TDD出的错只在最近一个引入的变化里，就好纠正多了。甚至他自己都能纠正。
博主很是赞同该同事的看法，并且作者认为：

tdd重要的不是测试代码本身，是解决问题的思维，也许可以泛化，哪怕没测试，如果能够做到快速验证，反馈，价值的
稳定叠加，有足够信心，也未尝不可。也许你会说测试可以cover功能，那么如果只有这一点的话，我更喜欢BDD
(behavior-driven
development)，因为这具有用户最终的使用价值。如果你说快速定位bug，我们我更倾向于BDD
(bug-driven
development，自创的)。这写都是TDD的结果导致的好处所在，而价值反馈思维才是实现TDD背后原理。
TDD驱使我们以结果导向，使得我们简单设计(并不是无设计)，日常重构我们的代码库，注重交付价值流稳定叠加。

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 wshten@gmail.com