结对编程2——单元测试【201421123073(我),201421123070(队友)】
题目描述:##
上一周大家为四则运算程序设计了2-3个新功能,本次在隔了一周之后,我们循序渐进地进阶。本次目标:
- 把计算模块提取出来,单独创建一个类。
- 针对提取出来的计算类的接口函数做单元测试。
需求分析##
- 抽出上次作业的计算模块。
- 对其中计算的各个方法进行单元测试。
测试过程:##
(先测试第一次作业生成的较简单的运算,再测试队友改进的复杂的运算)
原始类的测试过程:(简单的运算)###
(1):首先回顾一下这个分数类的结构:(方法返回的是一个结果类,详情请看第一次作业四则运算)####
因为方法传入的是一个分数对象,只有分子分母,操作符是随机生成的,所以不存在1++2这样的测试。这样的设计模式,使得传入的参数比较有约束。
(2):测试当中的四个方法加减乘除。(使用eclipse中的JUnit以及eclemma代码覆盖率插件)####
- 完整步骤
- 项目添加JUnit类库(eclipse自带的:右击项目->Build Path->Configure Build Path...->Libraries->Add Library...->JUnit)
- 项目相加eclemma插件(①:Help->Eclipse MarketPlace 到里面搜索eclemma安装。②:通过地址http://update.eclemma.org/在线安装 ③:第三方网站下载eclemma压缩包离线安装)
- 完成插件安装后,右击需要的测试的类->new ->JUnit Test Case 然后系统自动生成一个类名+Test的测试类,在里面填写测试代码。
- 完成测试代码后进行代码覆盖率测试。通过点击Dubug旁边的代码覆盖率按钮进行代码覆盖率测试。
(3):测试开始####
①:测试加法方法
测试用例:
测试结果:(有于代码较长,截图不方便,没有上图。后面会给出代码仓库地址,可以自行测试查看结果)可以看出这个类中的加法方法,代码都变绿色了,说明以上测试用例都覆盖了这个方法的代码。
**②:测试减法方法**
测试用例:
测试结果:同样可以看出在分数类中的减法方法代码变绿。
**③:测试乘法方法**
测试用例:
**④:测试除法方法**
JUnit的结果显示:
代码覆盖率的显示:
(4)测试结果分析####
- 可以看出测试的覆盖达到98.6% ,没有达到100% 是因为测试用例中还有set,get方法没有测试到,只涉及了简单的构造方法。
- 测试可以看出你的哪些代码是多余的,你的可能的测试用例都用上了,但是还是没有覆盖到那行代码,也是一种检查代码的一种方式。
(5)错误的代码率覆盖测试####
比如以上的测试,有存在测试的错误,JUnit和eclemma会很好的告诉你,点击JUnit窗口中的存在错误的测试方法会告诉你哪行错了,以及你期望得到的是什么,但是实际的结果是什么,非常方便。也就是上图右边第一行显示的信息那样。
队友改进的类的测试过程:(可计算小数,分数,整数,以及括号的混合运算)###
(1)计算表达式步骤####
- 中缀表达式转后缀表达式
- 计算后缀表达式得到结果
(2)测试中缀表达式转后缀表示式####
①:整数测试
②:小数测试
③:分数测试
④:括号测试
⑤:混合测试
⑥:优先级测试
⑦:最大公约数测试
(3)计算后缀表达式得到结果####
后缀表达式计算结果测试
(4)直接计算表达式的结果显示####
(5)表达式无效测试####
(6)代码覆盖率显示####
实现总结:##
[1]遇到的问题:
- 在插件安装上,安装eclemma插件时,由于一开始都是用在线安装,可能由于网络问题,或者服务器较远,无法获取远程服务器上的资源,总是超时。安装好几遍没有成功,导致作业进度慢,最后通过离线安装,下载对应的包,进行安装。这过程挺坎坷的,试了好几种方法都不行,由于自己对一些操作还不熟。
- eclemma不会使用,查看了一些资料和博客,以及示例查看用法。
[2]在隔了一周之后再看之前的代码,是否更能体会到下面这些东西
(1):良好的设计
良好的设计非常重要,结构化模块化编程对于管理和修改和扩展都是非常有帮助的。如果没有设计好,可能一开始还没有感觉,
但是后面进行功能扩展的时候会非常痛苦,会导致后续一系列的问题。所以开始设计时,一定要有模块化的思想。相互之间的联系尽量少,分层设计,这样容易修改和拓展。
(2): 编码规范
一定要有自己熟练而且正规的一个变量,方法等命名规则。
如果随便定义了a,b,c,x,y后续再看的时候,或者别人看的时候会很困难。这方面自己还要好好改进。
(3): 必要的注释
方法的注释以及关键代码的注释很重要,有时候自己写的方法可能比较复杂,但是别人使用的时候可能并不想研究怎么写的,而是只关注怎么用。
让别人看一下注释就知道怎么用,有什么效果。这个后面一定要好好使用和规范。
[3]体会收获
- 以前没有用过和接触过代码覆盖率的使用,发现这个工具挺有意思的,也很有用,可以检验自己代码有没有问题,存在的一些BUG,会不会有一些多余的代码永远执行不到的。
- 在处理式子的过程中自己都忘了当初写的逻辑,哪些情况做什么的,有的时候会没有测试到,返回去看看,可以再用测试的方法试试一些特殊情况达到最大覆盖率。
- 在代码的注释上没有做好,后续要多注意。
- 发现代码的命名等待细节还是有欠缺,有句话说得很对,一定要有命名的含义,注释等等,否则过不久自己都会忘记写的是什么。
PSP:##
代码仓库地址:https://git.coding.net/hts-technology/SoftwareEngineering.git