当前位置:网站首页>什么时候应该编写单元测试?什么是TDD?
什么时候应该编写单元测试?什么是TDD?
2022-04-23 01:36:00 【魏波-】
一、传统方法与TDD方法
1、有人认为软件编码完成后编写单元测试(传统方法),流程如下:

缺点:编写完功能代码再写单元测试会导致单元测试“粒度”比较粗。对同样的功能代码,如果采用TDD方案,结果可能是用10个“小”的单测来覆盖,每个单测比较简单易懂,可读性可维护性都比较好,重构时单测的改动不大;如果用传统方法写的单测,往往是用1个“大”的单测来覆盖,这个单测逻辑就比较复杂,因为它要测的东西很多,可读性可维护性就比较差。
2、后来越来越多的人选择在软件编码之前写单元测试,这种方法成为测试优先或测试驱动开发(Test-Driven Development,TDD),流程如下:

说明:首先编写一个失败的测试,然后创建产品代码,并确保这个测试通过,接下来是重构代码或创建另一个会失败的测试。具体流程是先写少量功能代码,紧接着写单元测试,重复这两个过程,直到完成功能代码开发。这样做的结果是:基本上功能代码开发完,单元测试也差不多完成了。
(1)编写一个会失败的测试,以证明产品中代码或者功能的缺失。
编写测试的时候,要假设产品代码已经能工作了,这样测试的失败就说明产品代码中有缺陷。这个测试最初会编译失败,只有在添加了需要的代码后,编译才能通过,然后测试可以运行,但是会失败,因为还没有实现所需的功能。
(2)编写符合测试预期的产品代码,使测试通过。
(3)重构代码。
如果测试通过了,你就可以编写下一个单元测试或者进行重构,使代码可读性更强或者去除重复代码等。重构可以在编写多个测试后进行,也可以在每个测试后都进行。重构是一项重要的实践,他确保代码更易读,更好维护,同时还依然能通过之前编写的所有测试。
二、成功进行TDD的三种核心技能
成功进行TDD需要三种技能:
1、编写优秀的测试,即可维护、可读、可靠。
2、在编码前编写测试。
3、良好的测试设计。
版权声明
本文为[魏波-]所创,转载请带上原文链接,感谢
https://weibo01.blog.csdn.net/article/details/124315663
边栏推荐
猜你喜欢

Small example of gin - get request 2-handle handles post requests

On regular expression matching cryptography

gin框架的学习--golang

无关联进程间通信 —— 命名管道的创建和使用

计蒜客:数独(DFS)

NR polar code VII - SCL (successful cancellation list coding)

Prince saves Princess (DFS)

Introduction to PCIe xdma IP core (with list) - mingdeyang science and Education (mdy edu. Com)

Slow response of analysis API

GBase 8s 备份介绍
随机推荐
The most understandable life cycle of dependency injection
再谈被动安全 教你看懂中保研碰撞测试的评级报告
GBase8s SQL 引擎框架简介
After ten years of testing experience, I have sorted out the most suitable software testing learning guide for you
Small example of gin - get request 1-handle handles get requests
Learning of gin framework -- golang
计蒜客:方程的解数
代码实现发邮件---sendemails
gin -get请求的小示例2-Handle处理post请求
Jerry's CPU performance test [chapter]
DFS奇偶性剪枝
“自虐神器”一夜爆火:用手柄控制自己的脸,代码自取,后果自负
Android sqliteopenhelper data table structure upgrade
计蒜客(踏青)(染色块问题的DFS和BFS解法)
d盘分给C盘后,数据库恢复挂起怎么办,求各位解答
蒜头君开公司(DFS全排列)
Gbase 8s存储结构简介及空间管理
Gbase 8t index
NR polar code VII - SCL (successful cancellation list coding)
Blocking granularity of gbase 8s concurrency control