课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
随着互联网的不断发展,越来越多的程序员都开始学习软件测试的相关技术知识,而单元测试又是软件测试中使用频率非常高的一种测试方法。今天我们就通过案例分析来了解一下,程序员如何正确看待单元测试。
单元测试只是一种局部模块测试,是诸多测试方案中的一种,认识到这一点可以避免我们为了测试而测试,或者为了指标而测试。
同时也应该认识到单元测试本身的覆盖能力也是有限的,全部用例的PASS和覆盖率都不能保证被测试模块的所有逻辑路径都有正确的行为。
是否对一个模块使用单元测试往往取决于这个模块的逻辑稳定性和业务类型
例如对于一个底层npm包项目,单元测试几乎是他的代码质量保障手段,这时就应该尽可能通过单元测试验证它在各种应用场景下的行为是否符合预期,来低成本地保证它每次发包和更新的质量。对这类项目,彻底应用BDD开发模式也会获得越来越高的开发效率收益。
而对于一个功能复杂的UI组件,除了单元测试,还有E2E测试,自动化回归测试,QA手动测试(:blush:)来保障它的代码质量。此时使用单元测试的边际效益可能不是高的,可以考虑通过别的手段来回归它的逻辑。也可以考虑在初版功能验证上线后通过快照测试(snapshot)来回归验证每一次迭代的逻辑。
单元测试的一个很重要的意义是帮助我们在开发阶段模拟出QA手动测试(:blush:)甚至线上使用场景下都不易触达的边界场景,如:
模拟个别浏览器下的JS版本
模拟某个URL状态
模拟某种本地缓存状态
模拟不同时区下的情形
模拟时间过了一个小时(这几乎只有单元测试能够做到)
等等
使用这类模拟对模块进行单元测试的边际效益是极高的,往往比QA去作等价的模拟快得多。
测试代码无需关心被测试模块的具体实现,点到为止地测试几种必要的流程场景即可。这一方面可以减少写测试逻辑的时间,一方面可以使得业务逻辑具有更大的实现自由度。
对一个业务模块,测试脚本只需要关心该模块所关联的所有外部性即可:
对于函数模块而言,控制它引用的模块、它的输入和它的副作用,验证它的输出和对副作用的影响
对于组件模块而言,控制它依赖的服务、它依赖的子组件、它的props和它的事件,验证它的渲染结果和props中回调的调用情况,而不应该关心它的state。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。