先测试再开发？TDD测试驱动开发了解一下？——软件测试圈

1、什么是TDD

        我第一次接触TDD这个概念，是在《代码整洁之道》中，作者鲍勃大叔在书中，写了一些关于测试代码的代码规 范，其实就提到了有关TDD三定律：

定律一： 在编写不能通过的单元测试前，不可编写生产代码
定律二： 只可编写刚好无法通过的单元测试，不能编译也算不能通过
定律三： 只可编写刚好足以通过当前失败测试的生存代码

我第一次读到这三个定律时，不能说是毫无头绪，只能说是一脸懵逼。 完全不知道作者想表达啥意思，也没有案例代码。 对此，我不得不网上查阅的很多相关文章，最后总结出来。

这三条定律将你限制在大概30秒一个的循环中。测试与生产代码一起编写，测试只比生产代码早写几秒钟。本文摘自《代码整洁之道》

2、传统开发方式

我们传统开发一个功能是这么开发的？

传统编码方式

1. ·需求分析，想不清楚细节，管他呢，先开始写
2. ·发现需求细节不明确，去跟业务人员确认
3. ·确认好几次终于写完所有逻辑
4. ·运行起来测试一下，靠，果然不工作，调试
5. ·调试好久终于工作了
6. ·转测试，QA测出bug,debug,打补丁
7. ·终于，代码可以工作了
8. ·一看代码烂的像坨屎，不敢动，动了还得手工测试，还得让QA测试，还得加班。 传统的开发方式，都是以开发为主，直接开始编写代码，代码出了问题，再去改，多改几次，你就会觉得这代码简 直就是屎山，想重构一下，又怕出新的问题。

3、TDD步骤

而TDD测试驱动开发是怎么做的呢？ TDD要求我们先根据需求去拆分任务，把一个大的任务拆分位各个模块，也就是一个个的函数，我们再去为这些函 数去编写最小的测试，再去写能让这个最小的测试通过的最小的实现。 TDD的生命周期图如下。

        这样做的好处是：

1.                 ·有助于我们提前澄清需求：
2.                 ·可以通过单元测试断言的诊断机制快速得出反馈：
3.                 ·当我们写完了所有的需求，会发现所有的需求都会被测试覆盖了。