浅谈为什么要写单元测试

更新日期: 2022-06-21阅读: 844标签: 测试

01、单元测试基本概念

在计算机编程中, 单元测试(又称为模块测试, Unit Testing)是针对程序模块(软件设计的最小单位)来进行正确性检验的测试工作,程序单元是应用的最小可测试部件 。在过程化编程中,一个单元就是单个程序、函数、过程等;对于面向对象编程,最小单元就是方法,包括基类(超类)、抽象类、或者派生类(子类)中的方法。

通常来说,程序员每修改一次程序就会进行最少一次单元测试,在编写程序的过程中前后很可能要进行多次单元测试,以证实程序达到软件规格书要求的工作目标,没有程序错误;虽然单元测试不是什么必须的,但也不坏,这牵涉到项目管理的政策决定。每个理想的测试案例独立于其它案例;为测试时隔离模块,经常使用stubs、mock或fake等测试马甲程序。

单元测试通常由开发/测试编写,用于确保他们所写的代码符合软件需求和遵循开发目标。


02、为什么要写单元测试

我们应用编程开发技术来开发一套系统并编写单元测试,并不是为了显示和满足我开发设计能力的表现。我们要做的是 如何让系统更加的健壮,把代码问题扼杀在摇篮中,并节省每个迭代底层代码带来的测试分析和回归成本 ,所以核心是如何更好、更高效地在开发阶段就发现问题,减少重复劳动,降低回归成本,在修改代码时不用担心受怕。再者,单元测试具有较高的测试覆盖度,且是最好的文档。


03、单元测试成本

诚然,在写单元测试时需要许多额外的工作量,我们经常听到:我们项目很紧张的,我已经007了,根本不可能有时间来写单元测试;我们这个需求只是临时的,这次用完就不需要用了...;我写的代码不可能有问题的,诸如此类。确实在第一次编写单元测试时可能需要花费相比需求本身多出两倍的时间。

但软件开发中有一条重要的定律叫 规模代价平方定律,也就是定位并修复一个BUG所需的代价正比于目标代码规模的平方。

比如:

  • 如果一个20行的函数刚写完时很快就能发现BUG,找到并修复这个BUG可能只需要1分钟;

  • 如果是在200行的一个类中,别人调用时发现BUG,阅读代码并定位问题可能就需要一个小时,对这个问题的修复以及重新代码评审又要花一个小时;

  • 如果在系统和系统联调的时候才发现这个问题,前面扯皮加定位问题就要半天时间,修改完成后重新验证、回归又是半天。

如果改这个BUG的人已经不是原作者的话,往往担心改了这个BUG又引入其它问题,于是修改方案就要拖一群人讨论半天,最终改完了要求QA作大范围的回归,结果还是还不放心。像支付宝体系内,有1000多个系统,可能从业务表象到定位到系统问题,可能需要找n个团队n个人一步一步沟通下去,可能导致处理慢影响到用户。

规模代价平方律是很多软件工程实践的核心思想。 根据平方律,为了减少错误修复的成本,要尽可能早的发现错误,在尽量小的范围内定位并修复错误。 由于这是一个平方律而非线性率,所有这方面的努力都是非常划算的。

综上所述,其实磨刀不误砍柴功,每个人应该对自身系统的每一行代码的质量负责,因为单元测试能够尽早在尽量小的范围内暴露错误,所以在整个项目开发过程来看,做好单元测试是能够带来降低成本、缩短工期的好处来的。


04、单元测试带来的潜在收益

  • 测试驱动实现,促使每一行代码都可测。

  • 接受代码多次修改,回归测试更加轻松,让应用程序长期处于稳定。

  • case-study行成正能量闭环。

  • 极大减少调试时间。

  • 促进更好的设计。

  • 用例就是文档。


05、单元测试编写要求

  • 给用例取一个描述性的、准确性的名字。

  • 消除测试用例之间的重复。

  • 测试用例彼此之间需要独立,测试用例之间不能相互依赖。

  • 测试用例需要尽可能的简单,用例结果为简单的顺序执行,无分支、循环等控制结果。

  • 用例能够自动判断正确与否,case fail时能够直接说明哪里的代码除了问题,无需借助debugger,不是在代码里写个System.out.println,人肉观察一下结果。

  • 用例的结果需要强校验:对于每个方法的单元测试,需要明确判断结果的输出。

  • 用例运行够快,一般运行时间在毫秒数量级。

  • 用例要有覆盖度,一般对于系统变更的单测行覆盖率应达到80%,具体视各团队而定。


06、junit使用

junit是一个由Erich Gamma和Kent Beck开发的开源测试框架,可以让你进行测试所需的重要事情。以创建一个FileReaderTester类来测试文件读取器,任何包含测试代码的类(即测试用例)都必须继承测试框架所提供的TestCase类,如图所示。



07、常用的断言

断言

说明

assertEquals(expected, actual)

查看两个对象是否相等。

assertNotEquals(first, second)

查看两个对象是否不相等。

assertNull(object)

查看对象是否为空

assertNotNull(object)

查看对象是否不为空。

assertSame(expected, actual)

测试期望值和实际值是否都引用同一个对象。

assertNotSame(unexpected, actual)

测试期望值和实际值是否没有引用同一个对象。

assertTrue(a)

测试a是否为 true(真)。

assertFalse(a)

测试a是否为 false(假)。


08、junit常用元数据

元数据

说明

@Before

使用了该元数据的方法在每个测试方法执行之前都要执行一次。

@After

使用了该元数据的方法在每个测试方法执行之后要执行一次。

@Test

测试方法,在这里可以测试期望异常和超时时间。


09、谁来写单元测试

谁来写单元测试一直是一个值得争论的问题,原因一般在于工期排期,下面简要分析开发和测试在写单测过程中面临的问题,及如何更好得配合来提升单测覆盖率及效率。

开发写单测

开发扎根系统深度,对自己写的代码最熟悉,开发写单元测试比较顺手效率比较高,每个开发都应该对自己编写的代码负责。但开发说我平时写业务代码就忙不过来了,哪有时间写单元测试?而且大部分开发并没有很好的测试思想,单元测试可能只是写个最简单的用例就完了,最终可能单元测试通过,但基本的功能还是有问题,这样的单测没有太大作用。

测试写单测

测试对系统间的广度有较好的把握,有比较好的测试思想,可以更好地保证用例的校验点和覆盖度。通过写单测测试能更好地了解具体代码结构、流程,对于后续的业务测试也有利。但测试也有很多需求要测试,测试对具体代码实现细节没有开发熟悉,遇上为了可测性需要重构的时候还是得开发花时间配合,效率上不如开发自己写。

对于类似场景,我认为 测试可以把测试思想赋能给开发,做到测试驱动开发。 TDD带来的最大好处是 提高了单元测试的覆盖率。

因为每一种语言都离不开条件分支、循环处理和函数调用等最基本的逻辑控制,我们抛开代码需要实现的具体业务逻辑,仅看代码结构的话,实际上所有的代码都是在对数据进行分类处理,每一次条件的判定都是一次分类处理,嵌套的条件判定或者循环执行,也是在做分类处理。如果有任何一个分类遗漏,都会产生缺陷;如果有任何一个分类错误,也会产生缺陷;如果分类正确也没有遗漏,但是分类时的处理逻辑错误,也同样会产生缺陷。

可见, 要做到代码功能逻辑正确,必须做到 分类正确并且完备无遗漏 , 同时每个分类的处理逻辑必须正确。

在具体的工程实践中,测试可以赋能开发 等价类划分 的能力,让开发把等价类运用到单元测试中, 测试同学在每次代码提交时详细CR开发提交的每一个单测用例。

  1. 如果要实现正确的功能逻辑,会有哪几种正常的输入;

  2. 是否有需要特殊处理的多种边界输入;

  3. 各种潜在非法输入的可能性以及如何处理。

最后,在初期时开发和测试都可以借助linke平台去分析未覆盖到的分支。


10、参考文档&推荐阅读

1.《程序员的职业素养》 http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata

2.《重构》

3.《测试驱动开发》

来源:蚂蚁研发效能

链接: https://www.fly63.com/article/detial/11781

测试工具比较:选Jest,不选Mocha

Jest的未来看起来非常令人激动!看到Jest推陈出新如此快速,我感觉它将很快成为整个React生态系统中大部分项目的首选工具。我建议,应该把测试迁移到Jest上去。

你需要了解的前端测试“金字塔”

如果您正在测试前端应用程序,则应该了解前端测试金字塔。在本文中,我们将看到前端测试金字塔是什么,以及如何使用它来创建全面的测试套件。

web网页性能测试工具都有哪些

作为前端开发,我们不仅需要满足产品需求功能的实现,同时也需要对自己做的网站进行安全、易用性、性能等方面的考虑。随着目前技术不断进步,web页面的性能测试工具也在不断完善,通过这些工具,我们可以客观的评价web网站的质量水平。

js单元测试工具-jest自动化测试

jest 是 facebook 开源的,用来进行单元测试的框架,可以测试 javascipt 和 react。jest 提供了非常方便的 API,可以对下面的场景方便的测试:一般函数、异步函数、测试的生命周期、react 测试

web测试要点、方法_web端测试大全总结

web测试大全,测试web网站有哪些点呢?主要包括:功能测试、兼容性测试、安全测试、输入框测试、用户权限测试等

前端性能测试工具整理简介_性能测试工具都有哪些?

前端性能测试工具都有哪些:Favicon、Open Graph、图片优化-压缩图像、CSS 优化-Autoprefixer、Purifycss、minify CSS、减少载入时间、GZIP、CDN、优化平台-Sentry、Google Tag Manager

不用写代码,也能做好接口测试

本文你将了解到:1、接口测试基本概念,包含什么是接口,什么是接口测试,为什么要做接口测试;2、接口测试用例设计,3、怎样不用写代码,也能快速的根据开发的API文档完成接口自动化测试脚本

Selenium打开浏览器加载慢的原因

在自动化元素定位操作中经常使用智能等待来加强定位的强壮性,主要就是因为WebDriver没有提供页面加载场景的方法;在使用JavaScript知识的突然心生灵感,可以使用JavaScript来配合验证页面加载,结果发现我真是井底之蛙。

power assert_更智能、优雅的全方位 assert 断言库

在写测试代码时,以往我们需要翻阅文档,学习各种 API 才能明白如何操作断言。而现在我们可以透过 power-assert 的 assert 方法来减轻调试压力。不仅如此,它还提供更加直观,具体的运行效果,帮助 DEBUG。写测试代码,其实可以很容易。

常用的web网站负载/压力/性能测试工具

在网站上线发布之前,我们除了必要的安全、功能测试外,往往还需要进行压力测试。通过模拟实际应用的软硬件环境及用户使用过程的系统负荷,长时间或超大负荷地运行测试软件。包括:Apache JMeter 、LoadRunner、NeoLoad等

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!