TDD 测试驱动开发
参考
https://www.cigniti.com/blog/7-best-practices-for-agile-test-driven-development/
避免过于复杂的函数
保持每个函数 自扫门前雪,与团队讨论保证每个测试用例覆盖了所有期望的函数功能
聚焦于你真正需要实现的
测试用例要清晰描述 期望的 最终实现的功能，并按照这个原则编写。
Maintain code austerity
在通过测试样例的前提下，尽可能保持代码可读，可迭代。
Test repeatedly
…编写过程中持续测试，CI等工具都可以
Maintain code sanctity
用git，Jenkins等工具…….?????
Application knowledge
文档维护，
In TDD, coding needs to be limited but effective in that it achieves its purpose without breaking anything else. Also, the new code should ideally pass the test case in the very first run. Maintaining adequate system documentation, including a repository of test cases and engaging team members with good application knowledge can ensure a smooth and successful project execution.
Know when to use TDD
任何延长或复杂的测试都会破坏TDD的目的。
TDD rules
你不被允许编写任何让单元测试挂掉的代码
Write only enough of a unit test to fail.
Write only enough production code to make the failing unit test pass.
就是说，不论是测试代码还是业务代码，都是足量，但又尽量少，【例子 红绿灯
red phase
首先 写一些 用户会需要的 ’需求‘ 而不是 ’测试‘
所以 你考虑的角度是类似BDD(行为驱动开发)的,你会在开发前首先写代码，假设它已经完成了
这个阶段你需要考虑代码的出入参数 如何被使用，需要注意的是再该阶段 关注你核心需要的，而不是写大量的
green phase
编码
注意的是，这部分主要关注的是按照 red phase部分的 代码，实现，在这部分，不需要过度关注 性能，代码复用，也不要改测试
代码的优化应该在todolist 或 重构的时候清理 整理
但你应该写 直接实现，且可迭代的代码
新的feature只要还没有测试，就不应该先实现
refactor phase
代码抽象 去重 等等
Final considerations Q&A
TDD 需要很多 多于普通编码的时间
当你熟练了 不会多很多，而在后续的持续开发中，将省时间
需要写多少
足够你测试开发的代码，的最少量，因为每个测试都会拖慢重构，但重构需要测试来支撑
分析设计框架
你依然需要，TDD无法替代，在TDD之前，应该先分析设计。
这个是我具体实践起来感觉 很重要也有难度的，如果你对业务和功能，没有实践过，那么你可能分析得设计得不全面，这样的情况下你的测试样例也实现的 有缺失。一个可能就是编码的过程可能发现测试不够，这样一个办法就是继续走cycle再改。而我之前的写python的实践时，就直接把测试ban掉了XD。还是走了先代码后测试的老路
100% coverage
不必，视图等常变的微量逻辑毫无必要写TDD测试
TDD 在examples上 工作得号，但实际代码上 很多代码未被测试
emmmmmmm….. 作者用TDD方法 写了一个俄罗斯方块
TDD 谁来写
这里的观点是TDD是开发写，而真正的测试是测试人员来写