
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
单元测试技术的应用随着互联网的不断发展而被众多软件测试程序员掌握,下面我们就通过案例分析来简单了解一下,单元测试技术实践常见问题分析。
单元测试,顾名思义,围绕“单元”的概念展开,它表示较大系统中非常小的孤立部分。对于一个单元是什么或它应该有多小没有正式的定义,但大多数人认为它对应于模块的单个功能(或对象的方法)。
通常,如果编写代码时没有考虑到单元测试,那么可能无法完全隔离地测试某些功能,因为它们可能具有某些外部依赖关系。为了解决这个问题,我们可以应用依赖倒置原则,用抽象代替具体。然后,这些抽象的内容可以用真实或模拟的实现代替,具体取决于代码是正常执行还是测试执行。
除此之外,单元测试应该专注于被测点。例如,如果一个函数包含将数据写入文件系统的代码,则该部分需要抽象出来,否则验证这种行为的测试将被视为集成测试,因为它的覆盖范围扩展到了文件系统。
考虑到上述因素,我们可以推断单元测试仅对验证给定函数内部的纯业务逻辑有用。单元测试不应该有副作用或扩展其覆盖范围,因为那属于集成测试领域。
如果您将单元测试本身视为一个目标,您很快就会发现,尽管付出了很多努力,但大多数测试仍无法为您提供所需的编程信心,这是因为它们对错误的内容做了测试。在许多情况下,针对更广泛交互的集成测试比单元测试更有益。
有趣的是,一些开发人员编写了集成测试,但仍然将它们称为单元测试,主要是由于概念的混淆。尽管可以对单元大小进行考究与争辩,但这使得术语的定义更加模糊。
为实现组件隔离,创建了大量抽象层。尽管抽象本身是一种非常强大和有用的技术,但抽象不可避免地会增加认知复杂性,从而使理解代码变得更加困难。
通过这种间接方式,我们终也会失去某种程度的封装,否则我们可以保持这种封装。例如,管理单个依赖项生命周期的责任从包含它们的组件转移到了其他一些不相关的服务(通常是依赖项容器)。
一些基础组件也可以委托给依赖注入框架,从而更容易配置、管理和激活依赖项。但是,这会降低可移植性,这在某些情况下可能是不可取的,例如在编写库时。
归根结底,单元测试会影响软件设计,但这是否是一件好事还存在很大争议。【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。