TDD:正确的项目开发思路

前端之家收集整理的这篇文章主要介绍了TDD:正确的项目开发思路前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

  从以下仅为个人观点,如有疑问和异议,请在评论下留言。

  从事Java开发已经有两年多,会开始考虑如何保障开发以及维护的稳定性,起因有二,一是公司项目总会有修不完的bug,每次的修复,总会引发新的问题出现,导致维护工作反反复复,新工作无法正常的开展;二是自己有创建网站的计划,希望能够避免类似公司项目这样的问题,导致效率低下。实际上,项目的开发,最本质的要求就是:

  • 提高开发效率

  • 减少维护成本

  为了实现这两个要求,看了很多相关的资料,总结出来以下三点:

  • 敏捷开发

  • 测试驱动开发

  • 重构

  敏捷开发属于方法论,需要经验丰富的从业者驱动;重构属于技术活,要靠技术功底深厚的大牛;这两点不在今天的讨论范围之内,因为都需要经验的沉淀,但是测试驱动开发不同,他属于意识流,无论是刚入门的菜鸟,还是工作十年的老鸟,只有具备正确的思考方式,才能够完成项目的开发。

  测试驱动开发,又名TDD,顾名思义,以测试用例驱动项目开发,与传统的发开模式不同。

  • 传统的开发模式:

    1. 功能点需求分析

    2. 根据功能点编码

    3. 反复测试

    4. 修正BUG

    5. 回归

    6. 功能上线

  • 测试驱动开发模式:

    1. 功能点需求分析

    2. 根据功能点编写测试用例

    3. 根据测试用例进行编码

    4. 反复测试

    5. 修正BUG

    6. 回归

    7. 功能上线

  传统模式和测试驱动开发模式的区别仅在于第二,第三点,这小小的差别,却对结果有着翻天覆地的影响,可谓差之毫厘,失之千里。测试用例的存在为什么会导致如此大的差距?根据不同的开发阶段,可以对测试驱动开发模式进行分析:

  • 设计阶段

    • 基于需求编写的测试用例,可以快速提供产品原型,防止后期需求与描述不符导致返工

    • 基于测试用例的类设计和接口设计,能更好地体现设计意图

  • 开发阶段

    • 通过多维度编写的测试用例,可以细致地定位需求的功能点,避免直接编码导致的考虑不周

    • 根据测试用例的划分,逐一击破各个小的功能点,最后集成总功能,属于良性的开发循环,避免一次性将总功能实现所带来的巨大压力

  • 代码重构阶段

    • 测试用例可以保证重构代码不会影响到非重构部分,为开发者提供勇气和信心,否则,会因为代码的耦合性而难以重构

  • 添加功能阶段

    • 添加新的测试用例,但新添加功能不应该影响旧的测试用例,以保证系统的稳定性

说白了,TDD具备以下几点优势:

  • 对需求负责(需求如何定义,测试用例就如何定义)

  • 多个测试用例可精确描述所有的功能

  • 根据功能点,面向对象设计(对象设计,属性设计,接口设计)【设计的时候,会考虑到开发与到的问题】

  • 编码的目的在于跑通一个个测试用例

  • 测试用例相当于指南针,可以确保重构时和重构后,功能依旧能正确运行

  • 功能开发 ,继续添加新的测试用例,以保证新功能能在新的测试用例正常运行的同时,确保旧功能也能运行

  • 测试代码要不断地更新,从最简单的测试代码到后来相对稳定的代码

  • 测试代码是最好的接口文档,运行测试实例,可以从代码层面理解功能

原文链接:https://www.f2er.com/javaschema/282965.html

猜你在找的设计模式相关文章