• 1
  • 1
分享
  • 先测试再开发?TDD测试驱动开发了解一下?——软件测试圈
  • 饭团🍙 2022-07-25 13:54:38 字数 4106 阅读 1997 收藏 1

1、什么是TDD

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

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

我第一次读到这三个定律时,不能说是毫无头绪,只能说是一脸懵逼。

完全不知道作者想表达啥意思,也没有案例代码。

对此,我不得不网上查阅的很多相关文章,最后总结出来。

TDD测试驱动开发,就是先写测试用例,再去开发功能。
这里测试驱动开发里的驱动是做动词,不是名词

好了,现在如果别人问你TDD是什么,你就可以直接这样告诉他。

2、传统开发方式

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

传统编码方式

  • 需求分析,想不清楚细节,管他呢,先开始写

  • 发现需求细节不明确,去跟业务人员确认

  • 确认好几次终于写完所有逻辑

  • 运行起来测试一下,靠,果然不工作,调试

  • 调试好久终于工作了

  • 转测试,QA 测出 bug,debug, 打补丁

  • 终于,代码可以工作了

  • 一看代码烂的像坨屎,不敢动,动了还得手工测试,还得让 QA 测试,还得加班…

传统的开发方式,都是以开发为主,直接开始编写代码,代码出了问题,再去改,多改几次,你就会觉得这代码简直就是屎山,想重构一下,又怕出新的问题。

3、TDD步骤

而TDD测试驱动开发是怎么做的呢?

TDD要求我们先根据需求去拆分任务,把一个大的任务拆分位各个模块,也就是一个个的函数,我们再去为这些函数去编写最小的测试,再去写能让这个最小的测试通过的最小的实现。

TDD的生命周期图如下。

1.png

这样做的好处是:

  • 有助于我们提前澄清需求;

  • 可以通过单元测试断言的诊断机制快速得出反馈;

  • 当我们写完了所有的需求,会发现所有的需求都会被测试覆盖了。

4、举个例子

正所谓,光说不练,假把式;下来我们来整个简单的例子去理解一下测试驱动开发;

假如我需要写个功能,分析用户上传的文本中,每个单词的数量,并且按照数量倒序排序,这个应该怎么实现:

比如说文本如下:

Hello world
Hello CSDN
Hello Boy
My name is Boy 
is is

那输出就是:

Hello 3
is 3
Boy 2
world 1
CSDN 1
My 1 
name 1

如果是新手或者是完全不懂代码设计的人拿到这样的功能,可能会这样写:

 public static void main(String[] args) throws Exception{
        String words = "";
        File file=new File("word.txt");
        Scanner sc=new Scanner(file);
        while(sc.hasNextLine()){
            String line=sc.nextLine();
            words = words + line + " ";
        }
        System.out.println(words);
        String[] wordArrays =  words.split(" ");
        HashMap<String,Integer> hashMap = new HashMap<>();
        for(int i=0;i<wordArrays.length;i++){
            Set<String> wordSet = hashMap.keySet();
            if(wordSet.contains(wordArrays[i])){
                Integer number=hashMap.get(wordArrays[i]);
                number++;
                hashMap.put(wordArrays[i],number);
            }else{
                hashMap.put(wordArrays[i],1);
            }
        }
        System.out.println("统计单词------------------");
        List<Map.Entry<String, Integer>> list = new ArrayList<Map.Entry<String, Integer>>(hashMap.entrySet()); //转换为list
        list.sort(new Comparator<Map.Entry<String, Integer>>() {
            @Override
            public int compare(Map.Entry<String, Integer> o1, Map.Entry<String, Integer> o2) {
                return o2.getValue().compareTo(o1.getValue());
            }
        });
        System.out.println(list);       
    }

好了,写完了,让我们运行一下:

2.png

运行结果貌似也没有问题,好了提交代码。

真的没有问题吗?统计单词的数目也没有问题,但是,如果后期,你要对这段代码做维护,要去修改这段代码,这段代码读起来是什么感觉?在我看来,这段代码,就是屎山。

代码里几乎完全没有注释,读这段代码,得从头开始往下读,如果其中一段代码出了问题,你必须在整段代码中寻找错误,非常浪费时间。

让我们来试试看TDD的写法,TDD要求首先要把一个功能,去拆分分成各个小功能,然后去为这些小功能写测试用例。

这个统计单词数目的代码应该怎么拆分,试着拆分成小功能一下(这里要注意一下,同样的功能,在拆分模块的时候,不同的人选择的拆分方法可能不同,一千个人里有一千个哈姆雷特,一千个人里也有一千种拆分方法)

7.png

拆分好后,我们就可以为这些功能编写测试用例了,

我们先编写测试用例,用assert断言测试用例是否通过,运行,我们可以看出,方法还没有进行开发,显示未通过。

3.png

这一步,就是TDD定律二中规定的

定律二: 只可编写刚好无法通过的单元测试,不能编译也算不能通过

下一步要做什么?我们看定律一

定律一: 在编写不能通过的单元测试前,不可编写生产代码

定律一反过来是什么意思,不就是编写好不能通过的单元测试后,就可以开始编写生产代码了吗?

于是开始编写生产代码进行测试

4.png

在这里,我们编写好了方法,在执行测试用例后,显示绿色,代表测试用例通过。

这时候又满足了第三定律

定律三:只可编写刚好足以通过当前失败测试的生存代码

我们的测试用例,专门测试一个小的功能,只为了通过这个方法。

下一步我们再重复以上步骤,去TDD其他模块。

直到TDD完所有模块,我们的功能就开发完了。

代码如下:

 public static void main(String[] args) throws Exception {
        //读取文件
        File file=new File("word.txt");
        String words = readFile(file);
        String[] s1 = words.split(" ");
        //单词记录到hashmap
        HashMap<String, Integer> stringIntegerHashMap = groupHashMap(s1);
        //排序
        List<Map.Entry<String, Integer>> entries = orderHashMap(stringIntegerHashMap);
        //输出
        System.out.println(entries);
    }

方法的代码太长,太展篇幅就不粘贴了,你看我们新的main方法,代码就比较简介,如果出了问题,只可能在这三个方法中其中,我们可以快速定位到方法中去,并且可以用之前编写的测试用例进行测试。

5、总结

关于TDD测试驱动开发,我感觉精髓就是对功能进行拆分,用测试用例去测试功能,我相信很多人,都不会去编写测试用例,代码写好后,就去页面上点几下,其实这是不太好的。因为如果这里的功能改动比较频繁,你每次去页面上通过点击的方式测试功能,你得打开浏览器,登录地址,寻找IP,为功能配置参数,这一套下来,真的非常耗费时间。

一次如果5分钟,10次就是50分钟。

而TDD建议的是什么?建议通过测试用例的方式去测试,它要求你必须编写好测试用例后再去写代码,这样就能保住,你每个小功能,都有一个测试用例,这样,之后你改一个地方,只要找到这个地方所对应的测试用例就能测试了,非常方便。

当然,TDD这种开发方法其实弊端也是很明显的,比如,大多数程序员,其实是怎么做测试的?就是直接重启项目,去页面上看看,功能对不对,测试用例?那是什么?我不是开发吗,我又不是测试。我去页面点几下测试,可能只需要几分钟,我去配置测试用例,八成等得二十分钟,所以大多数程序员可能还是会选择通过页面点击的方式去测试。

测试用例真的是没有必要的吗?如果你去新建一个Maven项目,你会发送,test目录和main目录是同一级别的。

5.png

我相信在设计的时候,可能设计者(设计Maven的程序员肯定是大佬中的大佬),也是认为测试用例是非常重要的,才会把test目录放在这个位置吧。


作者:i进击的攻城狮

原文链接:https://blog.csdn.net/qq_45171957/article/details/123441147

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 读者提问:在线二维码生成器有推荐的吗 ?阿常回答:有,草料二维码。官网地址:https://cli.im 阿常碎碎念:平时给小伙伴分享文件、图片、文章、音视频,用草料二维码很方便,推荐大家使用。看完今天的分享对你是不是有所启发呢,有任何想法都欢迎大家后台私信阿常,一起探讨交流。
            0 0 1003
            分享
          •   2022年早已过半,来个迟到的年中总结,说实话,2022,很迷茫,然后过的非常不如意,倒不是上一年的职业目标没达到,而是接下来的路根本不知道如何走。在没解决这个问题之前,或者说没搞清楚自己的方向之前,是迟迟不能落笔的,啊不,应该是落键盘。  下班后花了几天的时间研究了下测试的职业生涯规划,在许许多多的文章之中穿梭,结合前阵子和某公司t3级的大大面试,对自己接下来的几年职业规划,总算有了眉目,让恍惚的心总算有了着落。  先说我这三年坎坷的经历  刚毕业,计算机专业的我进入了软件测试这个行业,然后外包到了某bat公司,在今天看来,这间公司应该是学习资源最丰富的公司,可悲哀的是,基础能力薄弱,资...
            0 0 1581
            分享
          •   刷脸支付,刷脸进站,刷脸打卡,一“脸”走天下的时代悄然来临。人脸识别的技术让人们的生活告别繁琐,如何验证人脸识别技术的功能正确性、安全性、识别率等关键问题,在测试领域也逐渐成为至关重要的课题。本文将结合实际工作中的探索与总结,阐述如何针对人脸识别技术开展测试。  一、什么是人脸识别?  人脸识别是基于人的脸部特征信息进行身份识别的一种生物识别技术,用摄像机或摄像头采集含有人脸的图像或视频流,并自动在图像中检测和跟踪人脸,进而对检测到的人脸进行脸部识别的一系列相关技术。人脸识别技术分为人脸检测,人脸跟踪,人脸比对三个部分。通过人脸检测可以在复杂的背景和场景下判断是否存在活体面像,并将其分离出...
            14 15 1216
            分享
          • Flink和Strom都是时下较为流行的数据流平台,考虑以下一种应用场景:已经使用Strom完成了对于某一逻辑功能的开发,如果现在期望使用Flink实现相同的逻辑,那么就需要考虑如何使用Flink来对Strom任务的逻辑功能进行最简单的复现测试。使用Flink来测试Strom任务的逻辑主要存在两个最基本的问题:第一,Storm通过自定义的Bolt类实现自定义的逻辑,在Flink中如何实现?第二,Storm按照自定义标准实现数据分发的逻辑,在Flink中如何实现?本文主要通过两个最基本的Flink程序实例对上述两个使用Flink测试Strom任务逻辑存在的基本问题进行解答。第一个问题,我们可以通...
            0 0 1720
            分享
          • 前言今年是笔者本科毕业的第6年,在接近三十而立的年龄里,回首自己从毕业到现在的职业生涯,可以说是一波三折。趁着自己现在有时间,就做一个复盘和总结,分享给曾经和我一样迷茫的朋友,希望能够带给你一些启发。一、考研失利,“捡到”一个国企的offer笔者是某末流211大学电子信息工程专业科班出身的,大四那年有些不知道“天高地厚”地拒绝了本校保研,准备跨考复旦大学的金融专业研究生,结果当然是华丽丽地当了一回“分母”。话说那时候考研还不是很卷,如果我坚持考自己专业,应该也是可以上岸一所不错的学校的,但是造化弄人.......于是乎,完美地错过了当时的秋招,只能急匆匆地追赶春招的步伐。地球人都知道春招无论是...
            11 11 1029
            分享
      • 51testing软件测试圈微信