课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
软件测试是目前互联网行业中备受关注的一个互联网行业,许多软件的开发上线也都离不开软件测试这一环节,今天我们就一起来了解一下,软件测试单元测试实践案例分析。
1、单元测试依赖实现细节
基于Mock的单元测试的含义是,使用这种方法编写的任何测试本质上都是对实现敏感的。通过Mock特定的依赖项,您的测试将依赖于被测代码如何使用该依赖项,而该依赖项不受公共接口的约束。
这种额外的耦合通常会导致意想不到的问题,其中看似非破坏性的更改可能会导致测试失败,例如Mock失效。这非常令人沮丧,并终阻止开发人员重构代码,因为永远不清楚测试中的错误是来自实际的回归还是由于依赖于某些实现细节。
测试有状态的代码可能更加棘手,因为可能无法通过公开的接口观察变化。为了解决这个问题,您通常会注入一种能够记录函数何时被调用的模拟行为,以帮助您确保被测单元正确使用其依赖项。
当然,当测试不仅依赖于调用特定函数,还依赖于它发生了多少次调用或调用传递了哪些参数时,测试与实现之间的耦合度就更高了。以这种方式编写的测试只有在内部细节不发生变化时才有用,这非常不合理。
过多依赖实现细节也会使测试本身变得非常复杂,尤其是与其他许多模块交互或存在大量依赖项时。测试变得如此复杂,那么谁来编写测试用例来测试测试用例呢?
2、单元测试不关心用户行为
无论您正在开发什么类型的软件,其目标都是为终用户提供价值。事实上,我们编写自动化测试用例的主要原因是确保没有引入损害软件价值的缺陷。
在大多数情况下,用户通过一些顶级界面(如UI、CLI或API)使用软件。虽然代码本身可能涉及许多抽象层,但对用户而言重要的是他们实际看到的并与之交互的那一层。
系统的某些部分是否存在错误甚至没有关系,只要它永远不会出现在用户面前并且不会影响所提供的功能。相反,如果用户界面存在缺陷导致系统实际上不可用,那么即使我们对所有较低级别的代码进行全面覆盖,也并没有什么用处。
当然,如果你想确保某些东西正常工作,你必须检查那个确切的东西,看看它是否有效。在我们的案例中,获得软件开发信心的好方法是模拟真实用户如何与顶级界面交互,看看它是否按照预期正常工作。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。