TDD(Test-Driven Development)测试驱动开发

前端之家收集整理的这篇文章主要介绍了TDD(Test-Driven Development)测试驱动开发前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

测试驱动开发是敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践,但不只适用于XP(Extreme Programming),同样可以适用于其他开发方法和过程。@H_403_5@

  TDD的基本思路就是通过测试来推动整个开发的进行,但测试驱动开发并不只是单纯的测试工作,而是把需求分析,设计,质量控制量化的过程。   TDD的重要目的不仅仅是测试软件,测试工作保证代码质量仅仅是其中一部分,而且是在开发过程中帮助客户和程序员去除模棱两可的需求。TDD首先考虑使用需求(对象、功能、过程、接口等),主要是编写测试用例框架对功能的过程和接口进行设计,而测试框架可以持续进行验证。   优点:在任意一个开发节点都可以拿出一个可以使用,含少量bug并具一定功能的产品。   缺点:增加代码量。测试代码是系统代码的两倍或更多。   TDD = TFD + Refactoring   (TFD -- Test First Development)   计算机领域:   Test Drived Develop   测试驱动开发是一种开发方法,是开发人员参与的活动。 其效果是以可执行的形式文档化你的需求,迫使你分清职责隔离依赖以驱动你的设计,编织安全网以便将Bug扼杀在在摇篮状态,防止其逃逸。可传统测试人员的活动是试图找到已经逃逸的Bug。这两种活动都是必要的,而且毫不冲突,互为补充。   那么测试人员在新的特性还没开发完成之前做什么呢? 除了提前写测试用例,无论是自动化的还是非自动化的,而需要测试人员参加的一项重要活动,就是参与特性验收条件的制定。 之前经常发生开发人员按照自己的理解去编码,测试人员按照自己的理解去测试,直到开发完成,测试过程中才发现理解的不一致,开始产生争执并阻塞等待业务分析人员(如果幸运的话)或者行政主管(如果开发过程混乱的话)的仲裁。 解决办法就是,在开始开发新特性前的一刹那,由业务分析人员,测试人员,开发人员进行一次讨论,就验收条件达成一致并形成记录,然后测试人员和开发人员分头去写测试和实现。@H_403_5@

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