测试驱动开发
它是一种开发方式，是敏捷开发、极限编程的核心部分之一。
它的目标是：可运行的简洁的代码。
在TDD中，有着两项简单原则：
- 仅当测试化失败的时候，才编写新的代码（产品代码、功能代码）；
- 去掉重复的部分——重构。
从上产生出一组技术方面复杂的行为准则：
- 必须参考每次修改代码后代码运行状况的反馈，逐渐完成设计；
- 必须自己编写测试；
- 开发环境（如IDea）必须对细微的修改做出响应；
- 设计必须遵从高内聚、低耦合的原则，这便于实施测试。
从上两条原则也预示了TDD编程任务的先后顺序：
- 红色指示条——编写一个无法工作的简单测试（甚至说无法通过编译）
- 绿色指示条——迅速使测试工作起来（想方设法，竭尽手段）
- 重构——去掉单纯由于使测试工作起来而产生的重复部分（数据的重复-输入、输出）
所以TDD的经典三部曲就是：红色指示条——绿色指示条——重构。
面对问题时，要么一筹莫展，要么从简单的地方着手。那么这样做吧： 从简单的地方着手；编写自动化测试；通过每一次的重构添加一回设计上的构思。
简单的原则，蕴含了非常好的思维模式，同样给程序带来了很好的效果。可以说，除非有着与之对应的测试，不然是不应该存在任何产品代码——这样的编程，确保了所写的代码，全部都是可测试的，这些代码的正确性有着测试方法的保证，任何错误的修改都将立刻提示出来。这给了继续前进的勇气。 也可以说，当程序的现有工作代码全部都被测试所覆盖，这就极大降低了BUG潜伏的隐患。 既然是需要现有测试，那么就是说现在程序里没有任何功能代码，也是先写了测试，所以说写测试时候并不在意程序是否存在这个类或方法、字段，尽管写测试吧，等测试写完后，再想方设法使得测试迅速工作起来！重构是非常重要的，简单来说重构就是对现有代码的修改——对如何做而不是做什么。
END
2019年11月3日，09点44分
