[讨论] 多少公司有执行单元测试 分享

楼主: derekhsu (華麗的天下無雙)   2016-11-03 23:41:32
关于自动化测试可以参考我多年前的拙作
https://www.ptt.cc/bbs/Soft_Job/M.1338221262.A.0AC.html
不过现在我们在讨论单元测试,所以我将把我的文章内容缩小到“单元测试”
上面。
我待过四间公司,写过C#, PHP, Python, Java,而这四家公司不管小接案公司
,网络公司,跨国软件公司或是大型传统产业,通通都没有养成所有人普遍撰写
单元测试的习惯,倒是我听说一些朋友在比较偏小型的start up或是小型软件
公司,比较有在做Unit Test。
很多人在谈Unit Test的时候会把Unit Test跟Integration Test混在一起,然后
说Unit Test要付出很多effort,实际上,他是把Unit Test跟Integration Test
混在一起讲了。
虽然这些这些公司都因为种种原因没有做Unit Test的习惯,但是我在这四间公司
里面全部都有自己做Unit Test,而即使有做Unit Test,我的品质与速度都比其
他人要快。
很多人在做Unit Test有一个盲点,就是为了做单元测试而做单元测试,因为上面
一个方案下来,说我们的专案要有几个test case,要达到多少coverage rate,
这样才叫做品质好,却经常没有从Unit Test的ROI出发。
另外一项造成Unit Test会花上许多时间的原因,就是物件的依赖程度太高,又
不懂得使用Mocking技术或是没有让程式有足够的测试力,导致做单元测试会影响
到整体开发时程,这样单元测试就变成累赘了。
“你终究要测试你的程式的,为什么不做单元测试呢?”
如果你的单元测试是为了减少你的测试时间用的,减少测试时间进而减少整体
开发时间,那你为什么不做呢?
给一些还没有做单元测试的朋友一些体会到单元测试的切入点:
1. bug的单元测试
如果发现bug,尝试用单元测试的方式找到那段有问题的程式码,然后撰写一个
单元测试程式,以后回归测试时要执行这个测试。
2. 减少耗时的I/O
network, storage这些东西都会造成你后续测试的时候消耗很多时间,透过mocking
技术, 机制将这些I/O的部分都去除掉,每次测试执行时间可能从几分钟缩短到几秒
,这会是天差地别的差距。
3. 选择依赖关系高的程式来做
很多人在写单元测试的时候会挑外围的程式来说,这些外围程式大多没有太多的依赖
关系,所以出问题的机会也少,程式也相对容易理解,反观那些高依赖关系的程式,
由于跟其他类别之间大量耦合,要测试里面的内容相对来说困难许多,透过mocking
来切割待测类别与其他类别之间的依赖关系,这样就不用花这么多时间准备整合测试
资料。
反观依赖度低的类别,测试资料准备与验证相对简单,虽然做单元测试也快,但ROI
却很低,做久了,会很没有成就感。
4. 思考单元测试减少的加载时间
除非你有用JRebel或是类似的东西,否则你在开发Spring Java程式的时候不免必须
不断restart你的application或是你的container去bootstrap Spring managed beans
,这些在测试阶段会花上非常多的时间。
当然Spring有提供JUnitRunner或AbstractTestNGSpringContextTests来供你产生单元
测试用的spring context,但当你类别多的时候还是很花时间的,这时候如果透过具备
Mocking功能的单元测试来完成你程式码的测试作业,将可以大幅缩短之后的测试时间。
以上这几点达到的测试覆蓋率可能不太高,但你应该会找到程式要测试的重点,至于
单元测试是要程式开发前(TDD)或是开发之后做,这要看你使用什么样的mocking技术。
重点是不要为了去做Test而去Unit Test,重点是分析这样做以后能达到多少ROI。
最后再来谈谈“单元”,每个人对于单元的定义可能都有所不同,但基本上的认知是,
单元测试是在测试“程式码”最小界定范围为“一个function”或是一个类别,所以
单元测试的目的在于测试function或class是否有达到预期。
当然function或class之间是有dependency存在的,单元测试的目的是去除这些
dependency让整个测试可重复执行并且不会因为其他单元的问题或不存在而造成
待侧单元的错误。事实上我认为单元测试最大的关键是怎么透过各种方法去消灭
这些dependency的能力,实际上你学的不是测试方法,而是mocking方法。
如果你是用Java的话推荐使用无敌mocking framework JMockit,完全不用对你
现有的程式进行改造,一样可以mocking。
其他透过撰写测试的过程当中知道怎么样去规划元件之类的好处我就不说了,
台湾这边的软件产业之所以会有种种问题,一部分就因为对于unit test带来
的好处与方法没有正确的认知所导致。
作者: jaspreme206 (handsssssome)   2016-11-03 23:45:00
作者: GoalBased (Artificail Intelligence)   2016-11-03 23:46:00
旧系统,一开始没特别注重耦合相依的问题,到后来要写单元测试成本一定会很高,大家都要学如何重构、物件导向,之后在学单元测试的东西怎么在系统明明没问题的情况下说服上面做这件事情..
作者: pttworld (批踢踢世界)   2016-11-04 00:19:00
推。但可论述本人做单元测试与不做二者开发时程比较。与其他开发者的效率比较不是单元测试而是经验。
作者: jackblack   2016-11-04 00:25:00
偷偷推 Mockito
作者: Chris926926 (Jan Egeland)   2016-11-04 00:58:00
推,感谢分享
作者: tails32100 (Tails)   2016-11-04 01:10:00
推推,感谢分享
作者: blackacre (Black/White/Green acre)   2016-11-04 04:36:00
离题问一下D大,你现在主力开发语言是什么 P还是J?
作者: atst2 (atst2)   2016-11-04 07:01:00
为什么一直在UT上争执开发速度啊?UT的目的在于提高产出的品质与完成度不是吗?
作者: Trick   2016-11-04 07:18:00
就是酱没错
作者: etoanik (小温)   2016-11-04 08:09:00
Python有推荐的吗?
作者: SHANGOYANYI (彦一)   2016-11-04 09:07:00
偷推 mockito +1 XD
作者: gmoz ( This can't do that. )   2016-11-04 10:31:00
感谢分享
作者: atpx (秋雨的心情)   2016-11-04 10:48:00
感谢分享
作者: kimkao (魂萦梦牵)   2016-11-04 11:29:00
偷推Mockito +2 XD
楼主: derekhsu (華麗的天下無雙)   2016-11-04 13:32:00
我要反推Mokito,JMockit各方面屌打Mokito……只是不能拿来在Android上跑
作者: UncleB (B先生)   2016-11-04 15:56:00
Unit Test-->Integration Test-->System test
作者: sean0430 (NANA)   2016-11-04 18:08:00
写Android推Mockito+3 XD
作者: orange7986 (AnnoyingOrange)   2016-11-04 21:09:00
作者: turelyman (in vain)   2016-11-05 07:02:00
很详细的分享
作者: ntddt (灭顶,降公投罢免门槛)   2016-11-05 16:34:00
推分享~
作者: flowheart (生气就输了)   2016-11-06 22:33:00
作者: wddx (i7MOMO)   2016-11-07 01:31:00
推 谢谢分享
作者: siriusu (かがみは俺の嫁。)   2016-11-07 09:43:00

Links booklink

Contact Us: admin [ a t ] ucptt.com