你平时是怎么做单元测试的?
面试官心理预期
面试官询问单元测试并非仅仅想了解这一概念,背后可能考察面试者以下三个方面:
·对软件工程生命周期的熟悉程度,以及对测试阶段各种方法(包括单元测试、集成测试、冒烟测试等)和其重要性的理解。
· 面试者是否展现出足够的责任心,明白优秀的测试工作对自身代码负责的重要性。
· 优秀的单元测试用例也体现了开发者在设计和编码方面的基本素质。
基于以上三点,我们需要思考什么样的单元测试才能被视为有效?
高手回答
整个软件工程的生命周期大致分为以下阶段:
· 需求分析阶段:包括需求调研、设计和评审
· 设计阶段:主要集中在架构设计
· 开发阶段:正式开始编码工作
· 测试阶段:完成编码后,包括:
-自测:单元测试 -> 集成测试
- 提测:QA介入集成测试,进行多轮测试
· 发布阶段:QA完成测试后,可以进行上线,其中包括:
· 预发布:部署到线上环境,QA进行回归测试,逐步增加流量,观察是否存在异常
· 正式上线:若预发布无问题,则代码正式上线,根据灰度或A/B测试策略控制新功能流量比例,经过稳定运行一段时间无异常后,逐步放开全部流量。
我们再深入分析每个阶段发现缺陷的成本,主要指从发现到解决问题所需的人力时间成本:
· 需求分析阶段:如果设计评审发现不合理,可以选择不执行,仅需花费几个小时进行会议讨论。
· 设计阶段:架构设计也需要评审,同样只需要几个小时会议时间。
· 开发阶段:如果前两个阶段没有问题,小型功能修复通常需要几小时,大型功能可能需要几天甚至更长时间,可能导致开发出无效功能,需要重新设计和开发,带来重复劳动的局面。
· 测试阶段:无论是自测还是提测的集成测试,修复一个缺陷意味着重新部署代码,对于大型项目,启动时间可能是分钟级。不论是自测还是提测,修复多个缺陷会阻塞测试进度,多次部署累计的时间成本非常高。而单元测试一个案例通常只需要毫秒或秒级,做好单元测试可以显著提高效率。许多公司非常重视单元测试的覆盖率和有效性,甚至将单元测试纳入持续集成/持续交付流程,仅当所有单测通过才能部署。同时,QA团队也极为关注阻塞测试进度的情况。
· 发布阶段:通常经过QA严格测试后才进入发布阶段,虽然不会出现明显的缺陷,但也不能排除存在问题。某些缺陷可能在实际用户请求或高流量时才会显现,这些越过测试和预发布环境的问题可能会在线上直接暴露。灰度和A/B测试的部分目的是将线上问题造成的影响最小化。这也解释了即使在各大互联网公司,仍可能发生事故。这种情况不仅涉及时间成本,严重的缺陷可能带来直接的经济损失和用户流失,一旦程序员出现问题,将成为谈资。因此,许多公司非常重视缺陷漏测率,即测试阶段未发现的问题。
上述内容提到了单元测试的关键要点,以下是编写优质单元测试的方法总结:
如何编写单元测试
1. 单元测试代码与正式代码同等重要,需要清晰层次分明,命名符合实际场景,并且要有适当的注释。可借鉴《代码整洁之道》中的技巧,关键是要确保测试用例易于理解。
2. 不要盲目地追求覆盖率,而是要尽可能覆盖所有可能的场景。
3. 单元测试要保持可用性,纳入持续集成/持续交付流程。如果所有测试用例不能通过,就不允许部署。
4. 确保每次运行测试用例都是确定性的,不依赖外部变化和不确定因素,包括但不限于:
· 随机事件:例如随机数,最好使用模拟(Mock)进行控制;
· IO操作:无论是磁盘IO还是网络IO(如数据库、外部接口),都需要隔离,最好也进行模拟。
5. 必须包含断言,否则单元测试就失去了意义。不能只是简单地打印结果,人工观察,在运行所有测试用例时很少会花时间检查每一个输出。
6. 验证边界情况和异常情况,这两点经常被忽视。边界条件可能包括:
· 传入错误参数的反应;
· 依赖返回不正确结果的情况。
异常情况包括:
· 外部异常:依赖(内部或外部接口、数据库环境等)抛出异常将如何处理;
· 内部异常:代码本身抛出RuntimeException的后果。
7. 正式业务代码应该遵循单一职责原则,高内聚低耦合可使单元测试更简单,测试粒度更细致,覆盖率更高。每个方法或类应只负责一项任务,这样测试用例只需关注当前方法的有效性,而不需要考虑方法之间的调用。每个测试用例也应只关注一件事情。
另一个优秀的策略是采用测试驱动开发(TDD)方法,即先列出所有可能的测试用例,然后再开始实现逻辑代码。这种方式可以快速创建出完备的单元测试集合。值得注意的是,在国内很少有公司采用TDD开发模式。
领域驱动设计(DDD)强调明确的边界划分,事件风暴和防腐层的设计为测试驱动开发(TDD)和单元测试提供了良好的基础。领域驱动设计(DDD)中倡导清晰的边界划分,通过事件风暴和防腐层设计,为TDD和单元测试提供了有力支持。
前文提到使用Mock对象来隔离I/O操作和随机事件,当然,Mock也可以应用于各种依赖关系,比如Spring Bean之间的依赖、工具类、各种内部接口的依赖等。Mock的作用是模拟所依赖的资源,我们可以假定依赖操作是成功或失败的,这样测试只需关注自身代码对依赖产生的响应结果即可。
Java的单元测试
Java工程也可以集成Spock框架进行单元测试,Spock使用Groovy语言编写测试用例。由于Groovy是一种动态语言,非常灵活,非常适合编写简洁的单元测试代码。同时,Spock不仅局限于模拟(Mock),还提供各种高效的功能(这些是传统JUnit和Mockito无法实现的):
1. Spy:可以对部分资源进行模拟,方便地对同一类内相互调用的方法进行模拟和验证。
2. Mock:对依赖资源进行模拟,同时验证依赖资源被调用的次数。例如,测试Redis写功能时,可以模拟Redis客户端,验证传入方法的参数是否符合预期,以及验证Redis写入方法被调用的次数。
3. Stub:对依赖资源进行模拟返回一个结果,不关心调用次数或参数是否匹配预期。
4. 可以直接忽略待验证方法的成员封装级别,可以直接测试私有声明的方法和变量。
5. 基于数据驱动的测试:借助where关键词和数据表格的方式,在一个测试案例中验证要测试的参数和期望返回值的所有可能情况。
6. 可以方便地验证抛出的异常。
7. 与Spring集成方便:可以进行Spring框架的集成测试,包括对Spring MVC、Spring Boot的HTTP接口层进行单元测试,无需启动Web容器。
所以编写优秀的单元测试代码是卓越程序员的基本修养。因为针对有用户访问和无用户访问的项目,相同的代码甚至在极端用户流量下可能带来截然不同的效果。在面对极端用户流量时,每次修改一行代码上线都如履薄冰。怀着敬畏之心对待每一次上线和线上操作,至关重要。
感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取 文章来源:https://www.toymoban.com/news/detail-847491.html
文章来源地址https://www.toymoban.com/news/detail-847491.html
到了这里,关于大型企业通常如何进行单元测试?的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!