课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
单元测试是程序员在学习软件测试技术的时候需要重点掌握的一个测试方法,而本文我们就通过案例分析来了解一下,单元测试实践常见问题分析。
1.单元测试的目的有限
任何单元测试的目的都非常简单:在隔离范围内验证业务逻辑。单元测试是否是合适的工具,取决于实际的被测范围。
例如,对使用复杂的数学算法计算太阳时的方法进行单元测试是否有意义?答案很可能是肯定的。
而对向RESTAPI发送请求以获取地理坐标的方法进行单元测试是否有意义?答案很可能是否定的。
如果您将单元测试本身视为一个目标,您很快就会发现,尽管付出了很多努力,但大多数测试仍无法为您提供所需的编程信心,这是因为它们对错误的内容做了测试。在许多情况下,针对更广泛交互的集成测试比单元测试更有益。
有趣的是,一些开发人员编写了集成测试,但仍然将它们称为单元测试,主要是由于概念的混淆。尽管可以对单元大小进行考究与争辩,但这使得术语的定义更加模糊。
2.单元测试导致更复杂的设计
支持单元测试的流行的论点之一是它促使您以高度模块化的方式设计软件。这是建立在这样一个假设之上:当代码被分成许多较小的组件而不是几个较大的组件时,更容易理解。
但是,通常适得其反,功能终可能会变得分散。这使得评估代码变得更加困难,因为开发人员需要浏览构成单个内聚模块的多个组件。
此外,为实现组件隔离,创建了大量抽象层。尽管抽象本身是一种非常强大和有用的技术,但抽象不可避免地会增加认知复杂性,从而使理解代码变得更加困难。
通过这种间接方式,我们终也会失去某种程度的封装,否则我们可以保持这种封装。例如,管理单个依赖项生命周期的责任从包含它们的组件转移到了其他一些不相关的服务(通常是依赖项容器)。
一些基础组件也可以委托给依赖注入框架,从而更容易配置、管理和激活依赖项。但是,这会降低可移植性,这在某些情况下可能是不可取的,例如在编写库时。
归根结底,单元测试会影响软件设计,但这是否是一件好事还存在很大争议。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。