51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 1088|回复: 0

[转贴] 让我们一起聊聊单元测试的恩怨

[复制链接]
  • TA的每日心情
    无聊
    8 小时前
  • 签到天数: 919 天

    连续签到: 1 天

    [LV.10]测试总司令

    发表于 2022-3-31 09:39:49 | 显示全部楼层 |阅读模式
     单元测试是一个伟大的发明,同时也是一个操蛋的发明。只要团队碰它,几乎很难全身而退。
      如果是我们自己写的代码,那么,写写单元测试也无伤大雅。但我们绝大多数人,都是跟在别人后面打扫狗屎,或者是留给别人一堆狗屎。这时候,单元测试写起来,就有一种不情不愿的味道。
      没错,就是不想写!
      为了应付所谓的指标,我们要给那些遗留代码,将要发臭的代码上一剂良药:那就是自动化。假如这些糟心的代码,大部分交给机器去写,我想很多人是非常乐意的。
      squaretest
      有很多这样的工具,比如IDEA自带的。但是它只能生成一些表面功夫的东西,也就是生成一个骨架而已。

    说实话,并没有什么鸟用。根本就没减少我多少的工作量,该覆盖不到的代码,还是覆盖不到。
      这个时候,我们需要更高级一点的工具。经过测试,现在瞄准了squaretest。
      在IDEA的插件安装界面中,找到squaretest并安装之,你就会拥有这个功能。

    重启IDEA之后,从你的屎山中,找到最臭的那一块,然后就可以在菜单中找到这个工具,生成代码。
      中间的话,可能会让你选择一下语言,选择一下模版之类的,这对于一个搞软件的来说并不是难事,所以这里也不再啰嗦。

    好家伙,足足给我生成了上万行的test代码。这时候,无论是交给QA看,还是交给分析工具去玩,都能闪瞎它们的狗眼。
      hehehehehehe....漂亮!
      报错不少,还得微调一下参数。但大多数代码已经生成好了,已经节约了很大的力气了。

     其他工具
      这貌似不是一个好的赛道。因为很多工具都不怎么维护了,或者不怎么好用。用爱发电越来越行不通了。
      比如JUnitGenerator2.0,连JUnit5都不支持;AgitarOne,虽然只有30天的试用期,但主页也和上古怪兽一样;Randoop的使用,根本就不是为人类设计的;Analytix被google收购后,几乎进入了坟墓。
      squaretest,可以说是非常好用了。
      你需要单元测试么?
      很多人没得选,因为这是硬指标。如果你的工作流程有问题,单元测试不但不能增彩,反而会成为累赘。
      大多数情况下,单元测试不会减少bug,它们会根据bug进行调整,以适应正常代码;另外,如果你的代码都是一些简单的CRUD,写单元测试看不到任何有益的地方。
      这个现状,还是要从根源上找原因。
      中国式需求,变化奇快,临时需求多,要求快速交付。这些功能,往往复杂性比较低,编写的代码并不会产生过多的bug;由于变化快,编写的单元测试也没有通用的可能性;一次性的代码,写完之后可能永远不再修改,被扔在一个遗忘的角落。
      要写单元测试,你要确保你的单元测试多年之后还可以用。而不是等到项目尾声,为了达到指标而集中补充单元测试。单元测试要想发挥它的价值,需要在一开始就创建相关的代码,扪心自问,很多团队是做不到这一点的。
      做不到,就不要装。
      单元测试并不简单
      有意思的是,即使环境达到了要求,所有的接口都提前设计了,且保持较少的变动,我们依然无法推行单元测试。
      单元测试从来不是因为写单元测试有多困难,而是大多数代码,是无法写出好的单元测试的。
      在TDD(Test-Driven Development,测试驱动开发)模式下,测试的动作比开发早,属于预先设计接口定义的范畴。如果你在后期对接口进行了较多的变更,这种方式同样会让开发人员变的痛苦不堪。
      单元测试需要配合极限编程,经常对代码进行重构。这是设计腐化之后的一种补救式措施。但很多情况下,大家都害怕、拒绝对旧代码进行修改。工期和稳定性是常见的借口,这些借口看起来比扩展性和可测试性看起来更正常一些,也更能说服高层进行决策。
      没有几个技术决策者,能够在销售、产品、老板的重重压力下保持初心,做这种长远性的规划。所以说单元测试肯定是有用的,但却缺乏实施的土壤。按时上线、提前上线、bug数量,这些常见的指标,只反映了结果,那些去改进这些结果的措施,短期效应不是很明显的话,很容易就胎死腹中。
      单元测试还阻碍开发人员重构的动力。因为重构意味着要动很多的测试代码,往往很多人偷偷一评估,就放弃了。
      坚持对的事情
      选择一个优秀的团队,是非常重要的。大家都很专业,不会亏待你所信仰的正确。专业的人才在二流子团队中,会像一个小丑一样无助,大多数习以为常的经验,几乎无法实施。
      让人欣慰的是,追求原则的团队还是有的,正确的方式可以避免很多曲折的路线,抛掉技术债所造成的负面影响。能够加入这些团队,是非常幸福的事情。
      作为程序员,应该时刻保持这种好的习惯,不要因为赶工,忽略了代码的重构和测试。这些是一个专业的技术人员应有的素质,而不是寄希望于公司的大环境中。这些好的习惯,就像人的气质一样让人着迷,最终会让你超脱于其他人而受益。
      作为技术管理者,你要正确评估自己的公司环境,是不是具有单元测试的生长土壤。即使你明白单元测试是有益的,你也不得不做一些取舍。尤其是你判断项目只不过是你的垫脚石,3年之后肯定不会在自己的手里,你更会任由它自我腐烂掉。如此情况,大家都心知肚明,没人会对你说三道四。
      作为非技术管理人员,当有人为你提出类似这种耗费工期的,长远有益的建议,不要着急否定。看一看其他优秀的企业,是不是也曾因这些短暂的原地踏步而受益过。无知并不可怕,可怕的是不相信专业。如果你肯定了,给予支持,而不要半途而废。有意思的是,半途而废最终并不会废止,它同样会蜕变为形式主义,将一件美好的事情硬生生变成指标。
      End
      单元测试代码是无聊的、枯燥的,尤其是为别人写的代码补充单元测试。通常情况下,如果不发生bug,没有人会闲的蛋疼去动那一堆堆的屎山,除非是不自量力的小牛犊。
      这个时候,一个得心应手的工具,自动帮你完成这些操蛋的工作,让你的单元测试代码拥有和屎山一样的生命周期,不得不说是一件快事。






    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

    x
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-3-29 17:52 , Processed in 0.064778 second(s), 25 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表