
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
单元测试是每一位软件测试程序员都需要熟练掌握并应用的一个基础软件测试技术,而本文我们就通过案例分析来了解一下,单元测试技术应用都有哪些不足之处。
从逻辑上讲,由于单测很小且孤立,单元测试应该非常容易和快速地编写。不幸的是,这只是另一个似乎相当流行的谬论。
尽管前面基于模块化的考虑让各个组件彼此分开,但单元测试实际上并没有从中受益。事实上,单元测试的复杂性仅与单元具有的外部交互的数量成正比,因为您必须为每个外部的交互做出相应的工作以实现隔离,同时保证能够执行所需的行为。
除此之外,单测与被测代码非常紧密地耦合,这意味着任何对代码的更改都是双倍的,因为测试也需要更新。更糟糕的是,很少有开发人员觉得它做是一项诱人的任务,通常把它交给团队中更年轻的成员。
基于Mock的单元测试的含义是,使用这种方法编写的任何测试本质上都是对实现敏感的。通过Mock特定的依赖项,您的测试将依赖于被测代码如何使用该依赖项,而该依赖项不受公共接口的约束。
这种额外的耦合通常会导致意想不到的问题,其中看似非破坏性的更改可能会导致测试失败,例如Mock失效。这非常令人沮丧,并终阻止开发人员重构代码,因为永远不清楚测试中的错误是来自实际的回归还是由于依赖于某些实现细节。
当然,当测试不仅依赖于调用特定函数,还依赖于它发生了多少次调用或调用传递了哪些参数时,测试与实现之间的耦合度就更高了。以这种方式编写的测试只有在内部细节不发生变化时才有用,这非常不合理。
无论您正在开发什么类型的软件,其目标都是为终用户提供价值。事实上,我们编写自动化测试用例的主要原因是确保没有引入损害软件价值的缺陷。
在大多数情况下,用户通过一些顶级界面(如UI、CLI或API)使用软件。虽然代码本身可能涉及许多抽象层,但对用户而言重要的是他们实际看到的并与之交互的那一层。
系统的某些部分是否存在错误甚至没有关系,只要它永远不会出现在用户面前并且不会影响所提供的功能。相反,如果用户界面存在缺陷导致系统实际上不可用,那么即使我们对所有较低级别的代码进行全面覆盖,也并没有什么用处。
当然,如果你想确保某些东西正常工作,你必须检查那个确切的东西,看看它是否有效。在我们的案例中,获得软件开发信心的好方法是模拟真实用户如何与顶级界面交互,看看它是否按照预期正常工作。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。