KOK球盘体育
当前位置: KOK球盘体育 > 单元作文 >

谈谈为什么写单元测试

时间:2020-03-11 13:38来源:未知 作者:admin 点击:
KOK球盘体育

当前网址:http://www.wassei.com/danyuanzuowen/2020/0311/824.html

  来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。一个单元可能是

  由于缺乏单元测试认识、实践,导致对框架重构迷失目标。意识不足是很严重的问题,框架重构没有方向。因此,首要任务,就是对单元测试全面了解。

  一个机器,由各种细小的零件组成,如果其中某件零件坏了,机器运行故障。必须保证每个零件都按设计图要求的规格,机器才能正常运行。

  一个可单元测试的工程,会把业务、功能分割成规模更小、有独立的逻辑部件,称为单元。单元测试的目标,就是保证各个单元的逻辑正确性。单元测试保障工程各个“零件”按“规格”(需求)执行,从而保证整个“机器”(项目)运行正确,最大限度减少bug。

  由于每个单元有独立的逻辑,做单元测试时需要隔离外部依赖,确保这些依赖不影响验证逻辑。因为要把各种依赖分离,单元测试会促进工程进行组件拆分,整理工程依赖关系,更大程度减少代码耦合。这样写出来的代码,更好维护,更好扩展,从而提高代码质量。

  如果程序有bug,我们运行一次全部单元测试,找到不通过的测试,可以很快地定位对应的执行代码。修复代码后,运行对应的单元测试;如还不通过,继续修改,运行测试.....直到测试通过。

  对于Android项目,要测试某个功能点,不用单元测试的话,必须运行在真机、模拟器上,慢慢debug找到问题点。运行程序到真机,快则半分钟,慢则几分钟。junit只需在本地运行即可,就几秒的事(robolectric需要十几秒)。有时,写那个功能模块的员工已离职,APP运行出错(逻辑错误,非crash or exception),你根本就不知道调试哪个类。如果离职的员工之前写了单元测试,运行一下立马就找到问题点了。单元测试大大减少调试时间,从而达到节约时间成本的效果。

  重构,每个开发者都会经历,重构后把代码改坏了的情况并不少见。以往,写完一个框架,运行APP,没什么问题,完事。由于最初的框架并不是你写的,可谓牵一发动全身,你改1个方法导致整个框架运行失败....

  如果你有单元测试,情况大不相同。写完一个类,把单元测试写了,确保这个类逻辑正确;写第二个类,单元测试.....写100个类,道理一样,每个类做到第一点“保证逻辑正确性”,100个类拼在一起肯定不出问题。你大可以放心一边重构,一边运行APP;而不是整体重构完,提心跳胆地run。

  有些经验丰富的领导,或多或少都会要求团队写单元测试。对于有一定工作经验的队友,这要求挺合理;对于经验尚浅的、毕业生,恐怕要死要活了,连代码都写不好,还要写单元测试,are you kidding me?

  培训新人单元测试用法,是一项艰巨的任务。新人代码风格未形成,也不知道单元测试多重要,强制单元测试会让他们感到困惑,没办法按自己思路写代码。

  国外很多家喻户晓的开源项目,都有大量单元测试。例如,retrofitokhttpbutterknife.... 国外大牛都写单元测试,我们也写吧!

  很多读者都有这种想法,一开始满腔热血。当真要对自己项目单元测试时,便困难重重,很大原因是项目对单元测试不友好。最后只能对一些不痛不痒的工具类做单元测试,久而久之,当初美好愿望也不了了之。

  都是有些许年经验的老鸟,还天天被测试同学追bug,好意思么?花多一点时间写单元测试,确保没低级bug,还能彰显大牛风范,何乐而不为?

  笔者也是个不太相信自己代码的人,总觉得哪里会突然冒出莫名其妙的bug,也怕别人不小心改了自己的代码(被害妄想症),新版本上线提心跳胆......花点时间写单元测试,有事没事跑一下测试,确保原逻辑没问题,至少能睡安稳一点。

  Test-Driven Development, 测试驱动开发, 是敏捷开发的一项核心实践和技术,也是一种设计方法论。TDD原理是开发功能代码之前,先编写测试用例代码,然后针对测试用例编写功能代码,使其能够通过。由于TDD对开发人员要求非常高,跟传统开发思维不一样,因此实施起来相当困难。

  测试驱动开发有好处也有坏处。因为每个测试用例都是根据需求来的,或者说把一个大需求分解成若干小需求编写测试用例,所以测试用例写出来后,开发者写的执行代码,必须满足测试用例。如果测试不通过,则修改执行代码,直到测试用例通过。

  好处,通过测试的执行代码,肯定满足需求,而且有助于接口编程,降低代码耦合,也极大降低bug出现几率(如果是极限编程,几乎是不可能有bug)。坏处,1.投入开发资源(时间和精力);2.由于测试用例在未进行代码设计前写;很有可能限制开发者对代码整体设计;3.可能引起开发人员不满情绪,我觉得这点很严重,毕竟不是人人都喜欢单元测试,尽管单元测试会带给我们相当多的好处。

  单元测试确实会带给你相当多的好处,但不是立刻体验出来。正如买重疾保险,交了很多保费,没病没痛,十几年甚至几十年都用不上,最好就是一辈子用不上理赔,身体健康最重要。单元测试也一样,写了可以买个放心,对代码的一种保障,有bug尽快测出来,没bug就最好,总不能说“写那么多单元测试,结果测不出bug,浪费时间”吧?

  作为一名经验丰富的程序员,写单元测试更多的是对自己的代码负责。有测试用例的代码,别人更容易看懂,以后别人接手你的代码时,也可能放心做改动。

  多敲代码实践,多跟有单元测试经验的工程师交流,你会发现写单元测试获得的收益会更多。

  在广州生活,在创业公司上班,猥琐文艺码农。喜欢科学、历史,玩玩投资,偶尔独自旅行。希望成为独当一面的工程师。

  Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...

  1.测试与软件模型 软件开发生命周期模型指的是软件开发全过程、活动和任务的结构性框架。软件项目的开发包括:需求、设...

  1.测试与软件模型 软件开发生命周期模型指的是软件开发全过程、活动和任务的结构性框架。软件项目的开发包括:需求、设...

  理财不仅仅是单纯的赚钱,其实是对生活的有效管理。 学习中学到的观点、思维是可以用到生活的方方面面的,从而做事更加的...

------分隔线----------------------------