TDD测试驱动开发

在各种敏捷开发实践中，测试驱动开发(TDD)一直处在最核心的位置。

TDD的核心在于严格规定开发节奏，一次把需求理清，一次做对、消除返工，不用调试就能获得反馈。

这是一个找虐的过程，他让你在走每一步前都必须先想好要达到什么效果，每一步都有充分的测试覆盖。

里边有三个关键：

第一步任务分解：测试先行，分离关注点，并用单元测试表达；

第二步单元测试：遵循 Given-When-Then 三段式，符合极限编程原则；

第三步小步快走：此处的坑在于很多人容易一下写多，破坏TDD节奏。

但一旦会用，节省出的时间会远大于编写测试代码而产生的工作量总和。

你有没有想过为什么明明都知道有用，但我们就是不爱写单元测试？

很多人说需求急、没时间，就算想测试也找不到接缝。为啥呢？因为你写代码的时候压根就没想一会儿怎么测啊大哥。

那怎么办，后面交付压力还跟着呢。要不就先这样吧，先放着，等过两天有空了我再补。

基本功不过关不能全赖程序员，但凭本能开发+单元测试不到位，两个加起来就是天坑。

• 对需求把握不准，写完PM不认；
• 代码有没有坑不知道，3个月前写的代码一碰就虚；
• 添加新功能就破坏旧功能，测出一堆bug加班修，bug越修越多； 以上循环，就会陷进无限返工、低效率的焦油坑。