TDD打卡总结

两周的TDD打卡练习，刚开始很不适应，原来我们软件开发的过程都是先分析需求，理清思路,然后编写业务功能代码，最后补充单元测试，单元测试只是覆盖正常的功能。这种模式，到测试阶段bug成堆，不停地修改bug,测试，会导致软件质量比较低，后期维护成本高，更可能延长软件交付周期。使用TDD之后，发现这种TDD的方法在效率和质量上都有很大提升。首先TDD开发模式可以提前确认需求，减少开发过程的终端等待，采用小步快走的方式，节省调试时间（每写完一段代码，就可以很快的测试代码的正确性）, 再者，先编写测试，可以保证高测试覆盖率，功能分支基本都被覆盖到，同时大量的单元测试覆盖率，可以随时自动测试回归，保证原有功能未被破坏的同时快速添加新的功能，软件质量得到有效保证。

• 什么是TDD

  TDD（测试驱动开发）是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。

  TDD的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。

• 怎么TDD

  

  上面的图片形象的说明了TDD的基本流程: 红——绿——重构，完整的TDD的流程是：

  

  写一个测试用例——>运行测试——>写刚好能让测试通过的实现——>运行测试——>识别坏味道，用手法修改代码——>运行测试

• 怎么才能做好TDD

  对于怎么做好TDD这个问题，我很难回答好这个问题，接触TDD的时间不长，自身经验有待提高，只能说几点对这个问题的认识。

  首先，团队需要建立一个共识，团队成员都认可TDD的开发模式，并落地到日常的开发过程中，把TDD变成一种编程习惯，固有的思维模式。

  再者，加入一些敏捷开发、TDD驱动开发的团体，包括公众号、社区等，经常吸取领域内专家的意见。

  再有, 可以阅读一些专业书籍，掌握一些理论知识，从方法轮的高度提升认识，比如说《测试驱动开发》，《代码整洁之道》、《重构》等。

• 写在最后

  最近除了接触了TDD, 还在接触BDD(行为驱动开发),它对TDD的理念进行了扩展，在TDD中侧重点偏向开发，通过测试用例来规范约束开发者编写出质量更高、bug更少的代码。而BDD更加侧重设计，其要求在设计测试用例的时候对系统进行定义，倡导使用通用的语言将系统的行为描述出来，将系统设计和测试用例结合起来，从而以此为驱动进行开发工作。

  BDD的通用语言是一种近乎自然语言的描述软件的形式。传统的开发模式中，客户很难从技术层面理解问题，开发人员很难从业务需求考虑问题，基于这种通用语言形式可以尽可能的避免客户和开发者在沟通上的障碍，实现客户和开发者同时定义系统的需求。避免了因为理解需求不充分而带来的不必要的工作量。

  在后面的工作中，会继续深入落地TDD与BDD，通过更多的实践，掌握敏捷开发、实例化需求等技能。